Eigen Inlog?
Ik ben nieuw hier en zit te twijfelen of ik een inlogscript van deze website ga gebruiken of een eigen.
Als ik een inlogscript maak met sessie's, MD5, antiflood en MySQL is dit dan veilig genoeg? Of is dit snel te kraken?
Alvast bedankt!
edit:
Bekijk eens wat recente loginsystemen en het commentaar dat er bijstaat van mensen onderaan het geplaatste script. Daar kan je nog wat van opsteken. Succes.
Gewijzigd op 01/01/1970 01:00:00 door Kalle P
Arjan:
Ik zou geen wachtwoorden in een sessie zetten ofzo, maar je kan het prima als identificatienr/code gebruiker om vervolgens in de database die code te vergelijken.
nee dat doe ik ook niet, is ook niet nodig lijkt mij, maar waar dient die tutorial voor veilige sessies dan vor?
Als iemand inlogt en alles klopt zet ik een nieuwe row in de tabel tbl_secure met de inhoud: username/secure_code
Vervolgens creëer ik een cookie genaamd secure en met een unieke code van 18 karakters(dezelfde code die in de database staat) en een cookie met de username
Op elke pagina kijk je of er een cookie bestaat met die code en username, zo niet dan inlog-formulier laten weergeven.
Bij het inloggen verwijder je alle oude rows(voordat je een nieuwe toevoegt) met dat username(cookies verlopen natuurlijk) en hij het uitloggen ook.
Dirk Renes op 08/11/2011 09:00:30:
MD5 is eiegenlijk niet echt veilig salt is beter.
Ik neem aan dat je bedoelt dat md5(pass+salt) veiliger is dan md5(pass), maar zoiezo raad ik dat ook af, gewoon crypt gebruiken (phpass).
md5 is oud, achterhaald, heeft massale rainbow tables en het is gewoon een snel algoritme wat bruteforcen dus gewoon makkelijker maakt.
SHA1 raakt tegenwoordig steeds vaker in opmars...
- Aar - op 08/11/2011 10:06:33:
Tenzij je een salt gebruikt, dan heeft niemand wat aan een rainbow-table.
SHA1 raakt tegenwoordig steeds vaker in opmars...
SHA1 raakt tegenwoordig steeds vaker in opmars...
Dat is waar, maar met de steeds sneller wordende hardware zal het nogsteeds wel mogelijk zijn om de salt te achterhalen, dan zou je al haast een aparte salt per gebruiker moeten gebruiken wat natuurlijk ook een mogelijkheid blijft.
Het is natuurlijk ook hoe moeilijk je het ze wilt maken en hoe ver je zelf wilt gaan.
Smur f op 08/11/2011 10:47:39:
Dat is waar, maar met de steeds sneller wordende hardware zal het nogsteeds wel mogelijk zijn om de salt te achterhalen, dan zou je al haast een aparte salt per gebruiker moeten gebruiken wat natuurlijk ook een mogelijkheid blijft.
Hoe zou je dan een salt kunnen achterhalen???
Als jij dus altijd pass+salt doet, dan zul je dus een rainbow table kunnen maken met die salt.
Maar hoe langer je salt is, hoe groter de kans is op een colission dus hoe lastiger het wordt om het orgineel te achterhalen. Dit komt omdat er oneindig invoer mogelijkheden zijn en een beperkt aantal uitvoer mogelijkheden.
Met een salt ga je dus zorgen dat ze meer invoer mogelijkheden moeten proberen voordat ze het kunnen achterhalen en zorg je dat de kans dat, ALS ze een gelijke hash hebben gevonden en de invoer verschillend is, hoger wordt.
Het punt is dus, mogen ze dus de moeite nemen om een rainbow table te maken voor je hashes van gesalte wachtwoorden, ze dus bij de kortste wachtwoorden mogelijk al de salt kunnen achterhalen. Als dit zou gebeuren wordt het proces van de andere achterhalen gigantisch verkort, aangezien je het aantal mogelijkheden gigantisch gaat verlagen.
Dus in principe is het zo dat je eigenlijk verschillende salts wilt gebruiken, die lang zijn, het is namelijk niet zo erg dat ze een invoer vinden die dezelfde hash genereerd aangezien ze daar niets mee kunnen.
Het voordeel van crypt() (met behulp van bcrypt) is dus dat het genereren van rainbow tables dus gigantisch veel trager is aangezien bcrypt een algoritme is die traag is. Voor jou maakt een extra 10 ms niet uit, voor een bruteforcer wel :)
tl;dr:
hashes zijn handig als je ze goed toe past (het proces van het genereren van de juiste hash traag maken)
Edit: excuses voor de wall of text :P
Gewijzigd op 08/11/2011 11:34:01 door Jelle -
c6a5c55dda637108d317d11024b96436 en bdfb4aa7cc60785d05f9792835818eb8
Daar kun je toch nooit een salt uithalen???
Nog een simpel voorbeeld: je MD5't de letter a, dan krijg je:
0cc175b9c0f1b6a831c399e269772661
en nu aa, dan krijg je:
4124bc0a9335c27f086f24ba207a4912
Daar zitten toch totaal geen overeenkomsten in?
Je weet nu van 2 gebruikers het "wachtwoord":
bla_boom
bla_boek
Hmm, beide bla_ ervoor, zou dit de salt zijn? Grote kans van wel. Dus in plaats dat wij nu gaan bruteforcen met alle mogelijkheden beperken we dit dus tot "bla_" + alle mogelijkheden daar achter en ben je dus het effect van de salt zo ongeveer kwijt.
Als we nu een langere salt gebruiken, is er dus een grotere kans dat er een invoer is VOOR het echte wachtwoord die dezelfde hash genereerd.
Als voorbeeld hier van gebruiken we even een hash van 6 tegen maximaal (md5 heeft er 32)
Stel je voor we hebben asdfasdfasdfasdf_blaat, die geeft (bv) 123456 als hash.
We zien dus, het aantal tekens van het gehaste wachtwoord meer is dan de hash zelf is. Dus er is een grote kans dat als we gaan bruteforcen, we meerdere keren dezelfde hash krijgen met verschillende invoer. Dat maakt het achterhalen al weer een stukje lastiger.
Jij zegt "Het punt is, dat je dus met bruteforcen gewoon alle mogelijkheden af gaat en wanneer je bij 'bla_boom' komt, zie je dat de hashes overeen komen."
Ja, dat klopt... maar dit is toch helemaal niet reëel? Ten eerste begint het er al mee dat iemand niet weet op welke manier een wachtwoord is gecodeerd. Dan moet ie vervolgens denken... iemand zal vast als wachtwoord "boom" hebben, en dan ga je vervolgens "boom" bruteforcen met allerlei prefixes. En dan moet tussen die prefixes toevallig ook nog eens "bla_" staan. En in werkelijkheid gebruik je natuurlijk een of andere rare salt zoals "dfkj34s". Nou, ik denk niet dat iemand dat tussen z'n prefixes heeft staan. Gooi er dan ook nog een pepper bij... en dan ga je het toch nooit kunnen kraken :-s