Register uitlezen met activex? *

[Verwijderd]

Hallo,

Ik heb een vraag, het is een vrij ingewikkelde maar voor mij zeer nodig.

Ik ben op zoek naar een script dat informatie uit je regedit kan lezen. Dit moet gebeuren via PHP of Javascript of iemand die een betere manier weet.

Ik zal proberen uit te leggen waarom ik het nodig hebt en wat het precies moet doen.

Wij hebben een ChatSite genaamd Buzzen, en het probleem is dat we vaak geflood worden wat ertoe leid dat onze server vaak flinke floods te voorduren krijgt. Wij maken gebruik van een chat applet waarop gebruikers connecten, we zijn een vrij grote chat en hebben 20.000.000 hits per maand, dit alles maakt het voor sommige (foute) gebruikers erg interessant om eens te kijken hoe je een chat down geflood krijgt, meestal gebeurt dit via mIRC, een beruchte client waarmee je veel kunt maar vooral ook mee kunt flooden. Het chat applet van ons maakt gebruik van informatie dat weg wordt geschreven in het regedit waar onder andere de "ownerkey" en andere relevante informatie wordt weg geschreven dat de chat applet nodig heeft informatie te verwerken die gevraagd wordt door de chatserver.

Om floods te verminderen hebben wij een idee op gedaan om gebruikers via Chat Applet meer rechten te geven dan gebruikers die via mIRC connecten. Op deze manier zou 90% van de floods afnemen, en zal onze chatservers een lange uptime hebben.

Mijn vraag is daarom, bestaat er een PHP/JAVASCRIPT of iets anders wat in het regedit kan lezen of onze informatie erin staat zodat wij de gebruiker kunnen herkennen dat hij/zij via de web connect.

Ik hoop dat 1 van jullie Buzzen kan helpen, zodat wij flooders kunnen aanpakken.

Alvast bedankt,

Mvg,
Remko.

Buzzen Communications Inc.

[Orion84]

Uhm, regedit , je bedoeld het register? RegEdit is enkel een tool om je register handmatig te bewerken Op deze manier zal iemand die ooit in de toekomst deze vraag heeft dit topic niet zo makkelijk vinden,omdat de verkeerde termen worden gebruikt.

Of je vanuit PHP/javascript je register kan uitlezen zou ik niet weten, maar het zou me niks verbazen.

[ Voor 26% gewijzigd door Orion84 op 21-10-2005 09:58 ]

[Verwijderd]

Inderdaad register, maar als je regedit in je "uitvoeren" bij start invult krijg je register, ik kan helaas niet de topic titel aanpassen.

Hoop dat iemand het weet of het wel mogelijk is

[Borizz]

Je kan dus echt NIET met javascript of PHP een client side register uitlezen (Zonder bugs te gebruiken in de browsers in ieder geval)! Javascript draait in een beveiligde omgeving die echt niet gerechtigd is om het register uit te lezen. Ik vind het zowiezo raar dat je het register gebruikt in een applet. Nu valt het voordeel van een applet namelijk weg dat deze ook op OS X, Linux enz. draait.

Waarom niet een of andere vorm van flood control in je chatserver bouwen? Dat lijkt me beter dan dit clientside aanpassen, aangezien je zelf al aangeeft dat je ook een andere client kan gebruiken om verbinding te maken.

[Obliterator]

In PHP kan ik me nog voorstellen, maar als het in Javascript zou kunnen, dan waren er wel meer vuile Javascript virussen geweest.

Serverside is een betere oplossing idd. Meer dan zoveel tekens per seconde betekent een ban voor het IP adres. Dan is de lol er snel vanaf.

[ Voor 36% gewijzigd door Obliterator op 21-10-2005 10:08 ]

[Orion84]

Verwijderd schreef op vrijdag 21 oktober 2005 @ 10:02:
Inderdaad register, maar als je regedit in je "uitvoeren" bij start invult krijg je register, ik kan helaas niet de topic titel aanpassen.

Hoop dat iemand het weet of het wel mogelijk is

Je kan natuurlijk wel de inhoud van je Post aanpassen, de titel daar zorgt een modje wel voor
Opzich begrijpt iedereen je post waarschijnlijk wel, maar het gaat mee rom het principe. Als je met PHP iets van je hardeschijf wilt lezen dan ga je je toch ook niet afvragen of je php kunt koppelen aan windows verkenner?

Borizz schreef op vrijdag 21 oktober 2005 @ 10:06:
Je kan dus echt NIET met javascript of PHP een client side register uitlezen (Zonder bugs te gebruiken in de browsers in ieder geval)! Javascript draait in een beveiligde omgeving die echt niet gerechtigd is om het register uit te lezen. Ik vind het zowiezo raar dat je het register gebruikt in een applet. Nu valt het voordeel van een applet namelijk weg dat deze ook op OS X, Linux enz. draait.

Waarom niet een of andere vorm van flood control in je chatserver bouwen? Dat lijkt me beter dan dit clientside aanpassen, aangezien je zelf al aangeeft dat je ook een andere client kan gebruiken om verbinding te maken.

Volgens mij gaat het om serverside register? Namelijk de info die daar door de chatserver is ingezet. Op die chatserver draait ook een web chat applet en die moet blijkbaar bij de gegevens van de chatserver kunnen.

[ Voor 45% gewijzigd door Orion84 op 21-10-2005 10:10 ]

[ThunderNet]

Obliterator schreef op vrijdag 21 oktober 2005 @ 10:07:
In PHP kan ik me nog voorstellen, maar als het in Javascript zou kunnen, dan waren er wel meer vuile Javascript virussen geweest.

Serverside is een betere oplossing idd. Meer dan zoveel tekens per seconde betekent een ban voor het IP adres. Dan is de lol er snel vanaf.

hij wil het client-side doen.. dus dan gaat php al helemaal niet lukken

[sig69]

Ik vind het allemaal maar dubieus. Applets die in het register schrijven, en aan de hand daarvan flooders proberen tegen te gaan. Het lijkt me handiger om zoals reeds gezegd op iets anders te controleren (aantal tekens per seconde bv). Overtreding > ip ban. Klaar.

[Borizz]

Orion84 schreef op vrijdag 21 oktober 2005 @ 10:07:

Volgens mij gaat het om serverside register? Namelijk de info die daar door de chatserver is ingezet. Op die chatserver draait ook een web chat applet en die moet blijkbaar bij de gegevens van de chatserver kunnen.

Nu ik het nog eens lees, zou dat ook goed kunnen dat staat ook niet geweldig duidelijk in de TS. Dat zou met PHP misschien wel mogelijk zijn dan en als dit niet mogelijk is laat je het toch door de (server side) applet doen bij het connecten .

[ThunderNet]

Borizz schreef op vrijdag 21 oktober 2005 @ 10:14:
[...]

Nu ik het nog eens lees, zou dat ook goed kunnen dat staat ook niet geweldig duidelijk in de TS. Dat zou met PHP misschien wel mogelijk zijn dan en als dit niet mogelijk is laat je het toch door de (server side) applet doen bij het connecten .

in dat geval zou een database een betere optie zijn en die kun je wel zonder problemen met php gebruiken (server side that is)

[Orion84]

Borizz schreef op vrijdag 21 oktober 2005 @ 10:14:
[...]

Nu ik het nog eens lees, zou dat ook goed kunnen dat staat ook niet geweldig duidelijk in de TS. Dat zou met PHP misschien wel mogelijk zijn dan en als dit niet mogelijk is laat je het toch door de (server side) applet doen bij het connecten .

Dat lijkt mij ook logischer ja, dat je tijdens het connecten de applet zichzelf als zodanig laat identificeren. Moet je alleen de methode waarop dat identificeren gebeurt wel verstoppen voor de gebruiker, anders is dat waarschijnlijk ook weer te faken met mIRC.
En wat ik me ook afvraag, die applet als die connect, dan is dat toch vanaf het IP van de webserver waar ie draait? Dus dan is het een kwestie van dat IP (of die IP's als er meerdere servers zijn) een apparte status geven?

ThunderNet schreef op vrijdag 21 oktober 2005 @ 10:16:
[...]

in dat geval zou een database een betere optie zijn en die kun je wel zonder problemen met php gebruiken (server side that is)

Lijkt mij sowieso een veel betere oplossing dan al dat soort dingen in het register stoppen. Al weet ik niet of dat drastische effecten heeft op de performance.

[ Voor 22% gewijzigd door Orion84 op 21-10-2005 10:18 ]

[Verwijderd]

We hebben al een special Prot Server hiervoor die de "Montitor" houd over de chatservers, maar dit is lang niet genoeg, je kunt namelijk ook op andere manieren flooden dan alleen textflood etc.. textflood zijn onze servers makkelijk tegen bestand maar met mIRC kun je vuile trukjes... Daarom als je kunt zien wie er via "web" zit kun je mensen die "NIET" via web zit minder rechten geven op die manier kan er lastiger geflood worden.

We hebben in totaal 1 Directory Servers, 4 Chat Servers, 1 Prot Server.. als de diretory server geflood wordt kan ik je verzekeren dat de chatservers en protservers blijven draaien maar er niet connect kan worden met de chat omdat de directory server ervoor zorgt dat de gebruikers op 1 van de chatservers connecten. Je kunt je afvragen of je dit met de server allemaal wilt monitoren, omdat de protserver op dit moment al gebruikers killed of bant die flooden, maar als jij 100 clients in 1 keer connect en die in 1 keer laad flooden kan ik je verzekeren dat je dat niet kan tegen houden, mensen zijn nou eenmaal gewillig in het flooden van grotere websites.. Je kunt natuurlijk ook zeggen " Max 10 mensen connecten via zelfde IP " maar dan vinden ze weer een optie dat ze verschillende IP addressen gebruiken.. daarom is de oplossing die wij intern bespraken de beste oplossing..

Veel providers hebben "Zwevende IP addressen" dat ervoor zorgt dat een gebruiker moeilijk verbannen kan worden, of de gehele range waarbij je weer kans loopt om gebruikers te bannen die niks fout hebben gedaan..

Onze chat servers zijn IRCx speciale Protocol niet zoals de normale IRC servers. Onze chat applet heeft in het regedit bepaalde "ownerkeys" zitten (de gebruiker kan dan /pass (HIER DE KEY) typen om "Owner" status te krijgen bijvoorbeeld./ en ook andere dingen die belangrijk zijn om bijvoorbeeld succesful met de server te kunnen connecten, we hebben dit gedaan om scripten al lastiger naar onze server te connecten.

De opties die jullie noemen zijn gewoonweg niet de oplossing... inmiddels zijn de meeste middelen al geprobeerd van onze kant om floods tegen te gaan..

Mvg,
Remko

[Verwijderd]

Dat lijkt mij ook logischer ja, dat je tijdens het connecten de applet zichzelf als zodanig laat identificeren. Moet je alleen de methode waarop dat identificeren gebeurt wel verstoppen voor de gebruiker, anders is dat waarschijnlijk ook weer te faken met mIRC.
En wat ik me ook afvraag, die applet als die connect, dan is dat toch vanaf het IP van de webserver waar ie draait? Dus dan is het een kwestie van dat IP (of die IP's als er meerdere servers zijn) een apparte status geven?

Identificeren via chat applet is een optie, maar zoals ik al vertelde in me vorige topic hebben ze zelfs al de mogelijkheid gevonden om via een script te kunnen connecten.. " Ze laten de server denken dat ze via applet zijn " .. want connecten naar onze servers via /server irc. .. ext.. is niet mogelijk.. je moet een speciaal connectie script hebben wil je connecten.. deze is al te downloaden op bepaalde IRC sites..

[ThunderNet]

Is dat script niet beter te beveiligen dan? desnoods dat je hem elke week een klein beetje veranderd?

[Verwijderd]

ThunderNet schreef op vrijdag 21 oktober 2005 @ 10:28:
Is dat script niet beter te beveiligen dan? desnoods dat je hem elke week een klein beetje veranderd?

Onze medewerkers/programmeurs hebben het al druk zat denk niet dat het een optie is om elke week van onze kant scripts te veranderen om op die manier floods tegen te gaan..

[ThunderNet]

Verwijderd schreef op vrijdag 21 oktober 2005 @ 10:30:
[...]


Onze medewerkers/programmeurs hebben het al druk zat denk niet dat het een optie is om elke week van onze kant scripts te veranderen om op die manier floods tegen te gaan..

Toch zou ik ook naar die optie gaan kijken, je hebt geen ingewikkelde beveiliging nodig. Er zijn zat simpele beveiligingsmechanismen te vinden op internet, pas hier een paar van toe.

Daarnaast zou ik het register met rust laten, maar alles een Database doen (ook handiger met back-ups etc.) en via een database denk ik dat je zelfs wat performance winst kunt halen.

En misschien is het handig als je even de datastromen uittekend en hier post, zodat het voor ons iets duidelijker is wat er gebeurd

[blaataaps]

Ik heb even je topictitel aangepast, ik neem niet aan dat je regedit.exe wil lezen.
Ik denk ook dat de discussie inmiddels niet meer in WOS past, maar meer in SA

Voor de rest zie ik ook helemaal niet in hoe het zetten van een registerkey client-side je gaat helpen bij de stabiliteit van je irc-servertjes, maar dat ligt vast aan mij

edit:
Nogmaals gewijzigd,je begon in je topicstart over allerlei talen en een "applet" dus nam blijkbaar onterecht aan dat het om java ging

[ Voor 18% gewijzigd door blaataaps op 21-10-2005 10:53 ]

[Verwijderd]

ThunderNet schreef op vrijdag 21 oktober 2005 @ 10:33:
[...]

Toch zou ik ook naar die optie gaan kijken, je hebt geen ingewikkelde beveiliging nodig. Er zijn zat simpele beveiligingsmechanismen te vinden op internet, pas hier een paar van toe.

Daarnaast zou ik het register met rust laten, maar alles een Database doen (ook handiger met back-ups etc.) en via een database denk ik dat je zelfs wat performance winst kunt halen.

En misschien is het handig als je even de datastromen uittekend en hier post, zodat het voor ons iets duidelijker is wat er gebeurd

Register met rust laten doen we niet, heel veel wordt vanuit een database gehaald maar opties als "Ownerkeys" haal je niet uit een database dit is gevaarlijk, het moet elke keer anders zijn en de chat applet haalt dit uit het regedit en schrijft het weg naar de server zodat hij dat aan de "eigenschappen" van de chatruimte kan geven zodat de gebruiker "Owner status" kan krijgen..

Auth gaat al volgt;

Gebruiker logt in.. via de website.. geeft zijn gebruikersnaam en wachtwoord en vervolgens wordt vanuit ons database meer informatie gehaald. Vervolgens vraagt de chatserver "BIJ HET INLOGGEN" om een nickname, speciale code als identification en het wachtwoord. Vervolgens geeft de server informatie terug die voor de gebruiker nodig is om goed te kunnen connecten met de chatserver, zodat je elkaar niet kunt clonen en de mensen via script dit zelfde moeten doen en dus lang bezig zijn alvorens de met de chat connecten.. etc... dit veranderd elke keer, zo ook de "OWNERKEY" van de chatruimte.. om dit in je register te doen veranderd de ownerkey elke keer dat de gebruiker de computer opnieuw opstart en heb je een mindere kans op "Roomtakes"... wij hebben bewust voor dit systeem gekozen..

Ik ben niet echt van de technische kant, hiervoor hebben wij onze afdeling. Ik als "Website Managing director" heb de opdracht gekregen intern om uit te zoeken wat de mogelijkheden zijn van het uitlezen van informatie van de gebruiker die in de regedit staat bij onze software.. is dit mogelijk dan kan de opdracht gegeven worden aan 1 van onze programmeurs om het uit te voeren en deze "check" erop te maken.

Hoop dat het wat duidelijker is waarom wij gebruik maken van OOK de register..
En het werkt perfect op dit moment, gaat ook niet zomaar om al onze systemen nu aan te passen, wij hebben hier bewust voor gekozen en daar is lang over gesproken en duidelijke keuzes gemaakt betreft deze manier van communiceren met de gebruiker en chatservers.. waar het hier om gaat is de mogelijkheid van het uitlezen van de register..

[ThunderNet]

Maar je weet dat je dan elke vorm van platform onafhankelijkheid verliest?
Het hangt ook af van de browserinstellingen bij de client etc. etc.

Is het geen optie om te werken met cookies?

[Verwijderd]

blaataaps schreef op vrijdag 21 oktober 2005 @ 10:36:
Ik heb even je topictitel aangepast, ik neem niet aan dat je regedit.exe wil lezen.
Ik denk ook dat de discussie inmiddels niet meer in WOS past, maar meer in SA

Voor de rest zie ik ook helemaal niet in hoe het zetten van een registerkey client-side je gaat helpen bij de stabiliteit van je irc-servertjes, maar dat ligt vast aan mij

Topic Titel is niet toepasselijk..

Wij maken gebruik van ActiveX chat applet dat wordt gedownload met een .cab dat wordt gesaved op je computer.. dus geen JAVA ...

[Verwijderd]

ThunderNet schreef op vrijdag 21 oktober 2005 @ 10:47:
Maar je weet dat je dan elke vorm van platform onafhankelijkheid verliest?
Het hangt ook af van de browserinstellingen bij de client etc. etc.

Is het geen optie om te werken met cookies?

Onze chat is alleen toegankelijk voor Windows gebruikers, en voor IE en FireFox..

Cookies wordt al grotendeels mee gewerkt voor auth met de chatserver.. maar bepaalde dingen moeten met regedit en chat applet geregeld worden

[ThunderNet]

Wij maken gebruik van ActiveX chat applet dat wordt gedownload met een .cab dat wordt gesaved op je computer.. dus geen JAVA ...

Ok bij ActiveX heten die dingen dus geen applets.
applets is een naam die specifiek bij Java hoort

je maakt dus gebruik van een ActiveX control

Verwijderd schreef op vrijdag 21 oktober 2005 @ 10:50:
[...]


Onze chat is alleen toegankelijk voor Windows gebruikers, en voor IE en FireFox..

Cookies wordt al grotendeels mee gewerkt voor auth met de chatserver.. maar bepaalde dingen moeten met regedit en chat applet geregeld worden

huh ActiveX in Firefox... ik snap het nu niet helemaal meer
Geef asjeblieft een stroomdiagram en zoveel mogelijk informatie
(dus een getekende versie van je datastromen etc. ) misschien dat het dan wat duidelijker wordt

[ Voor 71% gewijzigd door ThunderNet op 21-10-2005 10:53 ]

[Verwijderd]

ThunderNet schreef op vrijdag 21 oktober 2005 @ 10:51:
Ok bij ActiveX heten die dingen dus geen applets.
applets is een naam die specifiek bij Java hoort

je maakt dus gebruik van een ActiveX control

"Chat Control" is de benaming hiervoor.. OCX officieel Sorry mijn techinsche kennis is wat minder betreft de benaming etc Bij ons wordt er altijd gesproken over chat applet.. ok verwarring excusses

[ Voor 12% gewijzigd door Verwijderd op 21-10-2005 10:53 ]

[SinergyX]

/offtopic
Ik zag dat het de MSN chat control programma is van MS zelf Mag je die tot bepaalde hoogte aanpassen?

[sig69]

Kijk nu komt de aap uit de mouw..
Verder vind ik het vreemd dat jij als "Website Managing director" dit moet uizoeken, lijkt me niet echt jou veld van expertise.

Ik als "Website Managing director" heb de opdracht gekregen intern om uit te zoeken wat de mogelijkheden zijn van het uitlezen van informatie van de gebruiker die in de regedit het register staat bij onze software.. is dit mogelijk dan kan de opdracht gegeven wo....

Dat doen jullie nu toch ook al? Waarom moet je dit nog uitzoeken dan? Ik snap het niet meer...

[ Voor 5% gewijzigd door sig69 op 21-10-2005 10:55 ]

[Verwijderd]

ThunderNet schreef op vrijdag 21 oktober 2005 @ 10:51:
[...]


Ok bij ActiveX heten die dingen dus geen applets.
applets is een naam die specifiek bij Java hoort

je maakt dus gebruik van een ActiveX control


[...]


huh ActiveX in Firefox... ik snap het nu niet helemaal meer
Geef asjeblieft een stroomdiagram en zoveel mogelijk informatie
(dus een getekende versie van je datastromen etc. ) misschien dat het dan wat duidelijker wordt

ActiveX in Firefox yup, is een speciale patch voor gemaakt;

<sub>Buzzen Installation Instructions for Mozilla Firefox:

Buzzen has made it possible for you to chat through Mozilla Firefox.
For Firefox capability in chat rooms, you must first download the Buzzen Chat Plugin>
If you have any questions you may opt to visit the official Firefox website here: http://www.getfirefox.com

For more information about Firefox : http://www.getfirefox.com

Click on the URL to begin downloading the Buzzen Plugin Installation Program. (Approximately 30 seconds on a 28k modem)
It is important that you remember to which directory you have saved the file.

Click "Save" to continue.
In the main menu of Firefox click on "File" and "Exit" to close your browser.

Locate the directory in which you saved the plugin. (NPPGWrap.exe) and left-doubleclick with your mouse to begin the installation.
On the file, you can click on open to carry out the task.</sub>

[Verwijderd]

Sinergy schreef op vrijdag 21 oktober 2005 @ 10:54:
/offtopic
Ik zag dat het de MSN chat control programma is van MS zelf Mag je die tot bepaalde hoogte aanpassen?

Nee t/m 2005 hebben wij officiele het recht om hiervan gebruik te maken.. hierna zijn we verplicht zelf een chat applet te gebruiken die door onze eigen software programmeurs zijn gemaakt, deze werkt op dezelfde manier en zal waarschijnlijk rond december released worden

[ Voor 3% gewijzigd door Verwijderd op 21-10-2005 10:58 ]

[ThunderNet]

Verwijderd schreef op vrijdag 21 oktober 2005 @ 10:57:
[...]


Nee t/m 2005 hebben wij officiele het recht om hiervan gebruik te maken.. hierna zijn we verplicht zelf een chat applet te gebruiken die door onze eigen software programmeurs zijn gemaakt, deze werkt op dezelfde manier en zal waarschijnlijk rond december released worden

Kun je die dan niet compleet anders aanpakken, zodat het wel werkt zonder deze (sorry dat ik het zeg) ranzige truukjes?


Register uitlezen: http://www.windowsdevcent.../15/VB_Registry_Keys.html

[ Voor 10% gewijzigd door ThunderNet op 21-10-2005 11:00 ]

[Verwijderd]

sig69 schreef op vrijdag 21 oktober 2005 @ 10:55:
Kijk nu komt de aap uit de mouw..
Verder vind ik het vreemd dat jij als "Website Managing director" dit moet uizoeken, lijkt me niet echt jou veld van expertise.

Ik heb mezelf aangeboden om het eerst zelf uit te zoeken en vervolgens als het mogelijk is hiervoor de opdracht te geven niks mis mee lijkt me toch? zo krijg ik ook nog meer kennis

[...]

Dat doen jullie nu toch ook al? Waarom moet je dit nog uitzoeken dan? Ik snap het niet meer...

We willen een extra check maken "NAAST" de chat control om het voor scripts onmogelijk te maken om de chatservers te laten denken dat jij via de website zit

[Verwijderd]

ThunderNet schreef op vrijdag 21 oktober 2005 @ 10:58:
[...]

Kun je die dan niet compleet anders aanpakken, zodat het wel werkt zonder deze (sorry dat ik het zeg) ranzige truukjes?


Register uitlezen: http://www.windowsdevcent.../15/VB_Registry_Keys.html

De meeste opties zijn onmogelijk of worden te makkelijk omzeilt.. vuile truukjes zijn het niet echt, het is allemaal toegestaan en hetgeen wat je in je regedit weg schrijft wat voor jou software geschikt is mag je zonder problemen uitlezen. (als dit mogelijk is) En voor de gebruikers is het alleen maar beter als de uptime hoger is

[Verwijderd]

@ThunderNet: Bedankt voor de URL, ik zal hem opslaan top!

[Verwijderd]

Iedereen die hierin mee wilde discussieren;

Heel erg bedankt voor de reacties, suggesties en hulp die jullie hebben geboden aan ons, maar ik moet weer aan het werk.

Ik zal maandag middag tijdens de vergadering dit onderwerp aandachtig naar voren brengen en een samenvatting maken van de suggesties die hier zijn gemaakt in dit topic. Alle suggesties na het posten van deze post zijn welkom, ik zal deze lezen als ik een samenvatting maakt van dit onderwerp. (In het engels omdat onze medewerkers geen Nederlands spreken )

---

P.s.

Al ons software is in C++ dus indien je aanraad aanpassingen te doen aan de nieuwe chat control zou het handig zijn als het C++ als programma taal bevat.

---


Nogmaals bedankt allemaal,
Namens Buzzen,

Remko.

[Obliterator]

Als mensen echt zo gebrand zijn op het flooden van jullie server, dan zal bijna elke actie die je client-side doet op een gegeven moment gebroken worden. Flood-control blijft toch iets voor de serverkant. Een aantal checks aan de clientkant, of extra info die de client naar de server stuur kan natuurlijk wel helpen.

Elke server kan gelimiteerd worden op het aantal connects dat hij accepteerd per tijdseenheid. Het is toch geen schande om bij overschreiding van dit aantal gewoon de extra connecties te weigeren. Als de 'hacker' ophoud, dan kan iedereen weer normaal inloggen en gaan er geen servers plat. Als de server al plat gaat vanwege het aantal connects, dan is er helemaal niets dat helpt.

[SinergyX]

Als je een perminente registry check erin wil bouwen, hoe zal dat verlopen bij de mensen met geen (of bijna geen) admin-rechten of een strakke firewall die dus toegang tot het registry blockt?

[KopjeThee]

Ik ben bang dat flood beheersing toch voornamelijk van de server kant moet komen. Maar goed, het klinkt alsof je wilt dat clients zich als het ware ook registreren en zich moeten identificeren, net als gebruikers. In dat geval zou ik clients in ieder geval ongeveer gelijk behandelen als gebruikers. Je geeft ze bij registratie (automatisch op moment van downloaden) een "naam" en "wachtwoord" (die ook niet bekend mag zijn bij de gebruiker van de client!!!), en misschien moeten ze die af en toe veranderen.

Het lijkt er op dat de OWNERKEY die rol ongeveer heeft. Ik kan niet nagaan hoe velig dit allemaal in jullie setup gebeurt, maar misschien kan het geen kwaad om eens wat over network security te lezen (heel leesbaar is bv de introductie in Computer Networks van A. Tanenbaum en dit kan je misschien wat aanwijzingen geven hoe dit probleem aan te pakken (denk aan Kerberos-achtige oplossingen) ).

Hoe je de "gebruikers" informatie van de clients opslaat en ontoegankelijk houdt voor anderen zou ik ook niet precies weten.