[C++] Veilige authenticatie tussen client en server

[spokey]

Voor een game client/server applicatie ben ik opzoek naar wat ideeen om een veilige authentificatie te krijgen tussen de clients en de server, op dit moment zit er eigenlijks helemaal geen beveiliging in maar alleen een simpele hello packet, die dus misbruikt word om bv server te flooden zodat hij altijd "vol" zit.

Omdat zo wel de client als de server applicatie voor iedereen beschikbaar moet zijn, heeft het bv niet zoveel zin om de hello packet te vervangen door iets "simpels" als bv een getal of code, omdat elke jan doedel dit uit de applicatie(s) zou kunnen halen.

[Creepy]

Heb je zelf al enig idee wat je hieraan kan doen? Heb je al eens beschrijvingen van het maken van een connectie naar een quake, ut, of cs server bekeken? Hoe deze werken is vrij simpel te achterhalen (zeker aangezien quake 1 en 2 geheel opensource zijn...)

Je zou ook eens kunnen zoeken op "challenge response". Maar ook dat weerhoudt niemand ervan om zo'n zelfde systeem na te maken om alleen de server te flooden. Daarnaast let je al op of iemand langer dan een bepaalde tijd niks heeft gedaan (idle)?

[wasigh]

Wat voor protocol je ook verzint, je zult altijd rekening moeten houden dat mensen socket's kunnen openen naar je server.
En je server zal daar op reageren. Als mensen heel veel verbindingen maken of heel veel foute berichten sturen om je server omzeel te helpen. Moet je zorgen dat je ze kunt bannen.

Via de socket kun je het IP van de gebruiker ophalen en dan laat je je code in de gaten houden of de user al meerdere connecties heeft. Zo ja, dan sluit je die af. Als iemand van een bepaald adres heel veel connecties wilt maken. weiger je alle connecties van dat adres.

kortom: je kunt mensen niet tegenhouden om connecties naar je server app (proberen) te maken. Je zult ervoor moeten zorgen dat ongeldige connecties zo snel mogelijk gesloten worden. Wat een ongeldige connectie is is natuurlijk afhankelijk van je applicaite.

[spokey]

De mogenlijkheid om idle connecties te disconnecten/blocken is al wel iets wat we zo wie zo willen meenemen, maar het flood verhaal ansich is niet het belangrijkste.

Ik had even wat duidelijker moeten zijn wat dat betreft, het gaat er voornamelijk om dat we zeker willen weten dat de originele client wordt gebruikt en niet een gemodificeerde client, het gaat er dus meer om de verificatie van client (versie) dan om het aanmelden ansich.

Alleen kun je dus via een aanmeld routine mooi een check uitlaten voeren om te zien of de juiste client word gebruikt, en de check moet iets "steviger" zijn dan een simpele versie nr.
Alles wat gemaakt word kan ook gekraakt worden dus 100% ben je nooit, het is meer dat het gewoon weer een stap lastiger word.

[Wolfboy]

Elke keer tijdens het verbinden een hash van de executable meesturen?
Wel een beetje goed verbergen in de code en eventueel nog iets anders meesturen maar dat zou opzich wel moeten werken denk ik.

[Verwijderd]

Probeer berichten te encrypten met public / private keys?

[Zoijar]

Je genereert een public/private key pair. Dan laat je mensen registreren op een website; dat kan slechts eenmalig (of je stuurt het mee met de cd...) Bij het maken van een connectie moet je dan een bepaald berichtje sturen (hash van de executables zou kunnen om andere dingen hacken lastiger te maken), dat encrypt de client op die private key (signature). Je server decrypt het met de public key, en kijkt of het klopt. Het mooie is dat de verantwoordelijkheid nu bij je client ligt, om de privatekey geheim te houden. De public keys mogen rustig uitlekken, daar kan je toch niets mee. Gevoelige data kan je server terug sturen door op de public key te encrypten, en de client kan dat decrypten met de private key.

(private key kan je over het net sturen, ofwel simpel met SSL, of met een DH key exchange)

[ Voor 7% gewijzigd door Zoijar op 06-01-2005 14:00 ]

[H!GHGuY]

Wolfboy schreef op donderdag 06 januari 2005 @ 13:32:
Elke keer tijdens het verbinden een hash van de executable meesturen?
Wel een beetje goed verbergen in de code en eventueel nog iets anders meesturen maar dat zou opzich wel moeten werken denk ik.

dit is natuurlijk op te vangen door 1malige met ethereal of zo deze hashcode op te vangen...

als je hasht kun je beter maken dat je enkele constanten + enkel verifieebrare dingen samenvoegt om te hashen. bvb:
- argv[0] => niet hacken => vaste naam = constante
- hash van de executable => idem = constante
- IP van client => verifieerbaar
- IP van server => verifieerbaar
- port van client en server => verifieerbaar
- size van de executable => constante
- ... ...

hoe je dit dan pcies in elkaar stopt is natuurlijk vrij...

[Zoijar]

HIGHGuY schreef op donderdag 06 januari 2005 @ 14:09:
dit is natuurlijk op te vangen door 1malige met ethereal of zo deze hashcode op te vangen...

Niet als je het signed, zoals boven met RSA. Dingen erbij stoppen etc, dat is geen security, maar obscurity. Je kan je logins prima crypto safe maken, dan mag het ook gewoon heel duidelijk zijn wat je precies stuurt. Een bekende string is genoeg. Wel waar dat als je hashes stuurt voor version control, dat je eventueel een andere hash zou kunnen sturen dan het echt is. Maar je key moet dan alsnog steeds valid zijn.

[spokey]

Idd zal alleen een md5 hash niet voldoende zijn, de packets die gestuurd worden tussen de server en client moeten per sessie kompleet verschillend zijn, anders zou je 1 malig het juiste pakketje kunnen "capturen" en weg is je beveiliging, maar dat zou weer opgelost kunnen worden met signen.

Ik heb iig al weer wat meer ideetjes, public en private key is maybe ook wel wat mee te doen, alleen gaat het om een al bestaande game waarvan de support al 2/3 jaar geleden gestopt is zodat je zelf dus iets moet bedenken. (zal game niet noemen om mensen niet op verkeerde ideeen te brengen)
Dus een private key uitdelen via website ofzo word weer lastig, omdat ik zo geen idee heb of je alle mensen daarmee wel bereikt, apparte tools of updates voor hun game vinden ze altijd wel via via.

[H!GHGuY]

mijn oplossing was bedoeld om te dienen zonder een paswoord/username. dan ben je redelijk aangewezen op obscurity...

want enkel met beveiligingsalgoritmes en meestal daarbij behorende usernames/paswoord kun je echt beveiliging implementeren op userlevel. maar dat was afaik niet echt de bedoeling.

[SPee]

Een soort handshake functie?

Client stuurt bepaalde key mee, server geeft een andere key terug. Client moet dan weer een andere key (afhankelijk van de server+client key) mee terugsturen? Dan krijgt hij een unieke (session) ID beschikbaar.

[curry684]

Tis trouwens 'authenticatie' niet 'authentificatie'. * curry684 fixt titel even

[yade]

offtopic:
* offtopic: het gaat ook niet echt specifiek over een C++ probleem...

Gewoon met accounts.

Een client moet hello sturen met een e-mail en een code. Is dit 3 keer onjuist dan blokkeer je het IP adres. (evt. op firewall niveau).

Via een site of gewoon in het spel kan de gebruiker zich registreren dmv het opgeven van een e-mail waarop de gebruiker dan een mailtje krijgt met de code waarmee gespeeld kan worden.

[miw]

Om de integriteit van de client software te verbeteren, kan je de client uitrusten met een voorziening (bijvoorbeeld een plug-in) om verificatie code te downloaden en te executeren. Deze verificatie code kan dan een aantal checks uitvoeren op de integriteit van de client software (die zijn in dit topic al eerder beschreven). Hierin kunnen dan ook real-time aspecten zitten, zodat je nooit twee keer hetzelfde antwoord krijgt. Je kan ook een tijdslimiet zetten op het executietijd van de verificatie code. Het aardige is dat de server nu ook verschillende verificatie modules kan opsturen met verschillende verificatie procedures.
Een aanvaller kan dan nog steeds eerst de originele applicatie opstarten en na de verificatie procedure switchen naar een gemodificeerde client software versie. Dit kan je moeilijk verhinderen, maar het is wel moeilijker te maken door meerdere keren de verificatie procedure te draaien en andere truuks. Je moet je dan gaan afvragen hoe ver je wilt gaan met het afdwingen van de integriteit van de client software.

[Wolfboy]

HIGHGuY schreef op donderdag 06 januari 2005 @ 14:09:
[...]

dit is natuurlijk op te vangen door 1malige met ethereal of zo deze hashcode op te vangen...

Daarbij zat ik dan te denken aan een challenge response systeem waarbij de server dus een bericht verstuurd (dat elke dag anders is) wat de client weer combineerd met zijn hash.
Maar nu ik er over nadenk is dat met een beetje reverse engineering best eenvoudig te krijgen

[spokey]

Met alle suggesties komen we vast al een heel eind, er word namelijk aan client side nog een heel aantal andere dingen ook veranderd ter voorkoming van debugging/disassembling en hooking en dat te samen met een server/client verificatie zou toch genoeg moeten zijn.

Ook zat ik nog te denken om zoiets als een punkbuster GUID like idee erbij in te doen, waarbij de GUID opgebouwd word uit een client en een server gedeelte, tevens zou dat een mooier vervanger kunnen worden voor IP banning want dat werkt toch niet in 7 van de 10 gevallen.

Ook zal de client dll`s en exe waarschijnlijk door een packer/encrypter gehaald worden om ook daar extra werk van te hebben.

Iig iedereen bedankt voor zijn/haar? input.

[Zoijar]

Denk eraan dat je niet maar zoveel mogelijk spul erin moet gooien, maar beter een goed doordacht, veilig, simpel iets. Hoe ingewikkelder je het maakt, hoe ingewikkelder het ook voor jezelf wordt om te kijken of het nou wel echt veilig is, of dat er gewoon een simpele manier omheen is.