VNC stopt er mee :(
Veiligheid
Tutorials praten over MD5 beveiliging, anderen branden het af, weer anderen stellen dan SHA1 de ware is, anderen zweren bij Salt's, dan is er nog een groepering into SHA256 en heb je de splintergroeperingen BPKDF2, BCrypt en PBMAC.
Ik zie door de bits de bytes niet meer.
Als ik een login wil maken voor een PHP browsergame. Wat zouden jullie aanraden? Ik zou heel graag ervaringen horen, want uit de tutorials kom ik geen wijs meer.
Denk ook eens over:
- Tokens.
- Captcha / IP Ban.
- Geef gebruiker niet te veel informatie.
- Logging.
Zo kan je nog wel een aantal dingen opnoemen..
Ik ga denk ik voor een brute mix van salt en pepper (http://createmy.com.au/php-password-salt-and-pepper-using-sha1-md5-hash/) (ik vind het iig een brute mix ;) )
Op deze manier is het wachtwoord iig beveiligd.
Captcha overweeg ik voor 5x niet correct ingelogt, om bruteforce te voorkomen.
IP logging om session stealing te voorkomen (ander IP? Uitloggen. Jammer voor de dynamische IP adressen :P)
Ik zou graag jullie mening horen of dit een veilige/handige combi is :)
P.s.Tokens snap ik niet, ik kom er ook niet echt duidelijk achter wat je voor veiligheidstruuks je kunt uithalen met ze. Zou je hier misschien wat meer over willen vertellen? (Het kan zijn dat ik nu hele stomme dingen vraag XD)
Nick Zwaal op 12/04/2011 11:08:44:
P.s.Tokens snap ik niet, ik kom er ook niet echt duidelijk achter wat je voor veiligheidstruuks je kunt uithalen met ze. Zou je hier misschien wat meer over willen vertellen? (Het kan zijn dat ik nu hele stomme dingen vraag XD)
Waarschijnlijk bedoelen ze tokens zoals je session_id. Het is een uniek en niet te raden identifier die dan aan de serverkant weer gekoppeld wordt aan data (zoals je sessie, het gegeven dat jij bent wie je zegt dat je bent etc) Maar als je PHP's sessies gebruikt doet PHP dat dus al voor je :)
Beveilig zo goed als nodig is, niet meer dan dat. Het is altijd een afweging tussen veiligheid en gebruikersgemak. Als je iemand na 10 minuten inactiviteit uitlogt is dat voor een banksite te verdedigen, maar het blijft vervelend en voor iets simpels als een forum zou ik het niet pikken.
Volgens mij iets wat ook geldt is, ga niet 2 hashes door elkaar gebruiken. Dus kies of voor md5 of voor een sha* functie.
Gerben Jacobs op 12/04/2011 12:06:28:
Probleem met md5 is, is dat er veel rainbow tables van op het internet staan. Dus het zou 'makkelijker' zijn om te bruteforcen.
Volgens mij iets wat ook geldt is, ga niet 2 hashes door elkaar gebruiken. Dus kies of voor md5 of voor een sha* functie.
Volgens mij iets wat ook geldt is, ga niet 2 hashes door elkaar gebruiken. Dus kies of voor md5 of voor een sha* functie.
En SHA1 en SHA256 door elkaar? Zou dat ook schadelijk zijn?
Jelmer rrrr op 12/04/2011 11:18:40:
Waarschijnlijk bedoelen ze tokens zoals je session_id. Het is een uniek en niet te raden identifier die dan aan de serverkant weer gekoppeld wordt aan data (zoals je sessie, het gegeven dat jij bent wie je zegt dat je bent etc) Maar als je PHP's sessies gebruikt doet PHP dat dus al voor je :)
Beveilig zo goed als nodig is, niet meer dan dat. Het is altijd een afweging tussen veiligheid en gebruikersgemak. Als je iemand na 10 minuten inactiviteit uitlogt is dat voor een banksite te verdedigen, maar het blijft vervelend en voor iets simpels als een forum zou ik het niet pikken.
Nick Zwaal op 12/04/2011 11:08:44:
-=snip=-
Waarschijnlijk bedoelen ze tokens zoals je session_id. Het is een uniek en niet te raden identifier die dan aan de serverkant weer gekoppeld wordt aan data (zoals je sessie, het gegeven dat jij bent wie je zegt dat je bent etc) Maar als je PHP's sessies gebruikt doet PHP dat dus al voor je :)
Beveilig zo goed als nodig is, niet meer dan dat. Het is altijd een afweging tussen veiligheid en gebruikersgemak. Als je iemand na 10 minuten inactiviteit uitlogt is dat voor een banksite te verdedigen, maar het blijft vervelend en voor iets simpels als een forum zou ik het niet pikken.
Ik wil graag zo min mogelijk hackers actief op mijn site, zoals elke siteowner (webmaster? Ik ben nog niet zo gewend aan de termen.) dat zal willen. Elke 10 minuten uitloggen vind ik wat aggressief, verandering van IP zowieso wel, meermaals wachtwoord proberen komt een captcha tegenover te staan. En het wachtwoord (en de username evt.) worden ge-SHA*'d. Het lijkt me zo redelijk veilig.
Denk ook na wat er gebeurd als een persoon gaat kloten met iemand anders zijn account (denk aan iemand die vergeten is uit te loggen op een openbare computer, of een vervelend broertje) Kan deze persoon dat aangeven? Kan je de 'schade' ongedaan maken?
Verder lijken me de ideeen die je nu toe hebt ruim voldoende qua beveiliging :)
Toevoeging op 12/04/2011 14:50:32:
Je hebt het over een browser spel, toch? In dat geval is het miss een idee om op elke pagina 1% kans heeft op een captcha, dit voorkomt dat mensen een bot schrijven die voor hun activiteiten gaat doet.
Denk ook na wat er gebeurd als een persoon gaat kloten met iemand anders zijn account (denk aan iemand die vergeten is uit te loggen op een openbare computer, of een vervelend broertje) Kan deze persoon dat aangeven? Kan je de 'schade' ongedaan maken?
Verder lijken me de ideeen die je nu toe hebt ruim voldoende qua beveiliging :)
Pim - op 12/04/2011 14:19:44:
Het hashen van wachtwoorden is maar een heel klein detail bij beveiliging. Belangrijk, maar een detail. (Veel) belangrijker zijn zaken als user input filtering/validatie.
Pim, bedoel je hiermee dingen als mysql_real_escape_string en het IP-adres waar het vandaan komt?
Johan Dam op 12/04/2011 14:34:21:
Je hebt het over een browser spel, toch? In dat geval is het miss een idee om op elke pagina 1% kans heeft op een captcha, dit voorkomt dat mensen een bot schrijven die voor hun activiteiten gaat doet.
Denk ook na wat er gebeurd als een persoon gaat kloten met iemand anders zijn account (denk aan iemand die vergeten is uit te loggen op een openbare computer, of een vervelend broertje) Kan deze persoon dat aangeven? Kan je de 'schade' ongedaan maken?
Verder lijken me de ideeen die je nu toe hebt ruim voldoende qua beveiliging :)
Denk ook na wat er gebeurd als een persoon gaat kloten met iemand anders zijn account (denk aan iemand die vergeten is uit te loggen op een openbare computer, of een vervelend broertje) Kan deze persoon dat aangeven? Kan je de 'schade' ongedaan maken?
Verder lijken me de ideeen die je nu toe hebt ruim voldoende qua beveiliging :)
Ik ben een beetje huiverig tegenover random captcha's op de site, zelf heb ik ze altijd als zeer irritant ervaren (hoewel dat de captcha's waren die onleesbaar waren gemaakt voor mensen :P, misschien dat ik reCaptcha kan proberen in beta :)). Zijn er naast captcha's misschien andere opties om botgebruik te voorkomen/verminderen/bemoeilijken?
Het reversen van de gemaakte schade zou met een rollback moeten gebeuren. Misschien dat het mogelijk is om een dag- of wekelijkse backup te maken waar de userdata dan uitgehaald kunnen worden, maar daar kan dan ook gebruik van worden gemaakt (alles overmaken naar een 2e account en dan rollback aanvragen). Dan zou voor het reversen een database bijgehouden moeten worden met alle transacties die gedaan zijn.
Het moet mogelijk zijn om uit te loggen wanneer je de pagina afsluit, ik denk dat dat voldoende beveiliging moet zijn voor openbare gelegenheden (weerwoord heb ik hier graag op!).
Maar gezien je met een spel bezig bent... je zal altijd mensen hebben die proberen vals te spelen. Een aantal daarvan kunnen programmeren en zullen scripts proberen te maken.
Na mijn weten zijn er 2 soorten scripts die ze kunnen maken,
Een klik-bot. Die werkt door de browser en klikt op bepaalde plekken. Deze zijn te voorkomen door een random margin op de 'attack' knop te zetten (bijvoorbeeld)
Deze heeft geen last van verborgen input dingen.
Een crawler-achtige bot die de html leest en post-acties uitvoerd afhangend van wat hij tegen komt. Deze heeft geen last van margins maar wel weer van captcha's. Ook kan je hem om de tuin leiden dmv van verborgen input velden / submit knoppen. Al is dit afhangend van de persoon die het gemaakt heeft.
Voor het automatisch uitloggen als ze de pagina sluiten.. miss eerst bij het inloggen vragen of ze op een openbare computer zitten? En zo ja, dan idd met een onunload oid automatisch laten uitloggen.
Als iemand gehackt is door zijn broertje ofzo.. dan zou ik zeggen, sorry maar helaas. Op het moment dat iemand tig mensen heeft gehackt, ja oke, dan inderdaad een complete rollback doen.
Een rollback per persoon is te moeilijk gezien hier misbruik van kan worden gemaakt.
Om tweede accounts tegen te gaan, houd accounts die onder hetzelfde IP geregistreerd staan in de gaten. Tuurlijk, 2 mensen kunnen dezelfde computer gebruiken en dus hetzelfde IP hebben, niks mis mee. Maar op het moment dat er 1 account niks anders doet dan dingen voor de ander (guild joinen, of niet levelen zodat het een makkelijk doelwit is en constant door het andere account aangevallen word), dan is het verdacht.
Ik zou je ook adviseren om af en toe een paar mensen die je vertrouwd te vragen om vals te spelen. Kijken of het ze lukt en zo ja, hoe je het later kan voorkomen.
Johan Dam op 12/04/2011 15:27:44:
Ik ben het met je eens in geval van captcha's, al kan je het zo simpel maken als een afbeelding die je vraag om 2 random getallen bij elkaar op te tellen...
-=snip=- (anders wordt deze thread wel héél lang)
...je het later kan voorkomen.
-=snip=- (anders wordt deze thread wel héél lang)
...je het later kan voorkomen.
Bedankt voor je respons!
De informatie over de twee bots die gebruikt kunnen worden is heel handig.
Ik denk dat mensen een openbare computer optie heel vaak zullen vergeten.
((EDIT: Tenzij die automatisch op true staat natuurlijk. Dan wordt dit opeens heel handig! ))
Tegenwoordig kan er gebruik gemaakt worden van het opslaan van je wachtwoord. Ik denk dat ik bij uitzetten gewoon de sessie moet laten beeindigen. (Desnoods leren ze hun paswoord snel typen ;))
Thuis kunnen mensen hun wachtwoord opslaan en zal men (vrijwel) direct doorgaan (een klik extra (login)).
Gewijzigd op 12/04/2011 18:30:39 door Nick Zwaal