Sha1 Md5 Salt
Wat is op dit moment de veiligste manier om je wachtwoorden op te slaan?
Iedereen heeft hier natuurlijk een andere mening over en PHPHulp bevat aardig wat artikelen hier over, maar die zijn alweer wat jaartjes oud en verschillen nog al erg van elkaar en zijn lang niet allemaal veilig.
Sommige gebruiken zelfs liever geen Sha1 of Md5 maar een eigen random stukje (klik).
Volgens de reacties van Lode is sha1/md5 onveilig omdat je altijd een vaste lengte hebt. Wat vinden jullie?
Op dit moment gebruik ik altijd sha1 zonder salt. Ik wil nou graag een salt gaan gebruiken om 't toch nog iets (of heel veel?) veiliger te maken, maar het enige wat een salt doet is een wachtwoord achter het wachtwoord plakken. Vinden jullie dit echt veilig? Of gebruik je een veiligere manier? En hoe ziet jou salt er ongeveer uit? (letters,cijfers,rare tekens,of gewoon een woord?)
md5($wachtwoord.$salt);
Je maakt dus een hash van het wachtwoord en de salt erbij, hierdoor krijg je een hele andere hash.
En Sha2 is een stuk veiliger dan sh1/md5
Chris Horeweg op 09/07/2010 13:49:44:
Zelf maak ik op een slimme manier gebruik van MD5, waardoor het wachtwoord niet meer kan worden teruggehaald.
Chris Horeweg op 09/07/2010 13:49:44:
Bruteforcen binnen het login-systeem moet je gewoon afketsen, zorgen dat dat niet lukt =)
Kun je een tipje van de sluier oplichten hoe je dat dan doet?
Obelix en Idefix op 09/07/2010 13:52:19:
Kun je een tipje van de sluier oplichten hoe je dat dan doet?
Login acties bijhouden (of in ieder geval de foute)
Bij een * aantal keer van een bepaald ip of een account dat ip/account voor eenn * tijd blokkeren. En dat steeds verhogen.
BV.
2* fout = 5 minuten
Daarna weer 2* fout = 10 minuten wachten.
Dan duurt het dus al 15 minuten voordat er 5 wachtwoorden getest kunnen worden.
Bij het succesvol inloggen laten zien dat er geprobeerd is in te loggen met een fout wachtwoord vanaf ip *.*.*.*
Eventueel na * (bijvoorbeeld 10) foute logins het wachtwoord resetten en dus de gebruiker een nieuwe mailen.
Over de encryptie van mijn wachtwoorden, daar vertel ik niets over. Door dat soort dingen geheim te houden, blijft het sterk =)
Wat bruteforcen op het formulier betreft kan je na zoveel keer foutief inloggen een captcha laten zien die eerst ingevuld moet worden voordat je weer een poging kan doen.
Elke keer een nieuwe salt genereren is leuk. Maar als je het gebruikt om de wachtwoorden op te slaan is dat niet handig. Je moet namelijk het wachtwoord later wel kunnen communiceren.
Johan Dam op 09/07/2010 14:44:13:
Ook zorgen dat je salt redelijk 'geheim' is, dus niet altijd "sUpErGeHeIm" gebruiken, maar op dat moment genereren, (bijvoorbeeld een hash van de microtime)
Wat bruteforcen op het formulier betreft kan je na zoveel keer foutief inloggen een captcha laten zien die eerst ingevuld moet worden voordat je weer een poging kan doen.
Wat bruteforcen op het formulier betreft kan je na zoveel keer foutief inloggen een captcha laten zien die eerst ingevuld moet worden voordat je weer een poging kan doen.
Ligt er overigens wel aan wat voor soort CAPTCHA je gebruikt. Er zijn genoeg CAPTCHA's al gekraakt namelijk... ;-)
Edit:
Verder overigens eens met TJVB, vandaar dat ik daar niet op reageer ;-)
Gewijzigd op 09/07/2010 14:55:31 door Chris -
Zelf haal ik m'n salts altijd van https://www.grc.com/passwords.htm. Verder zijn alle goede dingen al genoemd.
Chris Horeweg op 09/07/2010 14:16:18:
Over de encryptie van mijn wachtwoorden, daar vertel ik niets over. Door dat soort dingen geheim te houden, blijft het sterk =)
Security through obscurity... jaaa, die methode heeft zich prima bewezen. Het is veilig omdat ik het niet vertel ipv het is veilig omdat ik wiskundig/logisch bewezen heb dat het veilig is, en anderen dat met mij eens zijn. Doet met denken aan een "ander" debat.
Anyway, salt dient volgens mij alleen maar om rainbow tables minder bruikbaar te maken. Door salt aan je wachtwoorden toe te voegen, zorg je ervoor dat die langer wordt, en daardoor hopelijk meer uniek. Zo is de kans dat 'ie al in een rainbow table staat minder groot. Daarnaast als je hem langer maakt is de kans op collisions (twee verschillende reeksen die dezelfde hash opleveren) groter, wat dit maal in je voordeel werkt. Immers, stel dat je aan de hand van de hash het origineel vindt, dan moet je nog het wachtwoord van de salt scheiden om vervolgens in te kunnen loggen. Stel dat je een collision vindt, dan kan je het wachtwoord niet van het salt scheiden omdat je een compleet andere tekenreeks voor je hebt.
Brute-force kraken van de hash is ook lastiger, omdat je de salt moet weten of ook mee moet gokken. Lange reeks = veel mogelijkheden, dus lastiger. Daarom moet je die salt ook goed geheim houden. Je zou meerdere salt-reeksen kunnen nemen en op verschillende plekken kunnen opslaan (eentje in je PHP code, eentje in de database die uniek is per gebruiker) om zo de schade van het lekken van zo'n salt-reeks te beperken.
De manier waarop je ze vervolgens weer aan elkaar plakt, en hoe je het wachtwoord erin mengt kan verschillen. Je zou ze achter elkaar kunnen plakken, of de hash van wachtwoord + php-salt en daarna de hash van die hash + database-record-salt erover halen, al denk ik dat alles achter elkaar plakken veiliger is omdat je dan een langere reeks krijgt, en er dus meer mogelijkheden zijn die je moet verkennen wil je de reeks op basis van de hash goed gokken.
Gewijzigd op 09/07/2010 16:04:06 door Jelmer -
Chris Horeweg op 09/07/2010 13:49:44:
Zelf maak ik op een slimme manier gebruik van MD5, waardoor het wachtwoord niet meer kan worden teruggehaald.
Jammer dat je je geheim niet met ons deelt ;) waarom geen SHA1?
@TJVB: Goed idee om deze login veiligheid in te bouwen :)
Wat is nou een goede salt? Random en dan bij elke gebruiker een andere salt opslaan in de database? Maakt 't nog uit of je er speciale tekens in gebruikt?
Salt is dus alleen handig als iemand de hash weet te krijgen zodat ie deze niet kan bruteforcen. Om bruteforce op je login te voorkomen kun je 't idee van TJVB gebruiken.
Gewijzigd op 09/07/2010 17:35:42 door Michael -
Sander de Vos op 09/07/2010 19:57:05:
Dus iemand met een dynamisch IP mag/kan jouw systeem niet gebruiken?
Als iemand overstapt van ISP moet hij een nieuw wachtwoord aanvragen?
..etc
Niek s op 09/07/2010 20:31:24:
Dus iemand met een dynamisch IP mag/kan jouw systeem niet gebruiken?
Als iemand overstapt van ISP moet hij een nieuw wachtwoord aanvragen?
..etc
Sander de Vos op 09/07/2010 19:57:05:
Dus iemand met een dynamisch IP mag/kan jouw systeem niet gebruiken?
Als iemand overstapt van ISP moet hij een nieuw wachtwoord aanvragen?
..etc
Dit is maar een voorbeeld hoor, ik wil de salt ook wel veranderen naar 123.
Edit:
SALT is nu 123
Gewijzigd op 09/07/2010 23:12:34 door Sander de Vos
Ik weet dat dit een topic van een jaar geleden is, maar het gebruik van onderstaande combinatiemogelijkheid is toch ook een goede optie. Wat vinden jullie?
sha1(md5($wachtwoord.$salt));
Overigens kan het gebruik van een IP voor controle in sommige situaties handig zijn. Persoonlijk ben ik daar niet zo'n voorstander van.
Verder voeg ik altijd een salt + pepper toe doormiddel van uniqid + random letters. Ik plaats tussen de salt + pepper en het wachtwoord altijd een aantal tekens, zodat ik simpel het wachtwoord eruit kan halen. Die aantal tekens ertussen zijn dan random tekens, maar wel met regelmaat. Bijv. <cijfer><letter><letter><cijfer><letter>
En ik had juist meegekregen dat het gebruik van een dubbele encryptie (dus twee encryptiemethoden) weer beter zou zijn.
Ik vraag me wel eens af hoe ver we hier in door moeten gaan. We kunnen nooit spreken van 100% veiligheid, maar wel van 100% inzet aan preventie.
Ik neem een string $str die hash ik met de functie hash(). Hieruit krijg ik de string $hash. Maar $hash krijg ik ook door $andere_string door de hash()-functie te halen.
We hebben nu dus:
Code (php)
1
2
2
hash($string) - $hash
hash($andere_string) /
hash($andere_string) /
Stel we versleutelen deze $hash nu met de functie andere_hash() [LET OP: DIT HOEFT NIET PER SE EEN ANDERE HASH TE ZIJN, DIT KAN OOK DEZELFDE FUNCTIE IN EEN ANDERE FUNCTIENAAM ZIJN!] en daar krijgen we $double_hashed uit. Maar ook $compleet_andere_string geeft $double_hashed na de hash- & de andere_hash-functie.
Dus:
Code (php)
1
2
3
2
3
andere_hash( hash($compleet_andere_string) ) \
hash($string) - $hash -> andere_hash($hash) - $double_hashed
hash($andere_string) /
hash($string) - $hash -> andere_hash($hash) - $double_hashed
hash($andere_string) /
Nu heb je dus nog meer manieren om bij $double_hashes uit te komen... Dit probleem ontstaat doordat elke hash een surjectie is. Bij encryptie is dit niet het geval: encryptie is injectief. Vandaar dit verschil.
Het probleem is nu dus dat je drie wachtwoorden hebt waarmee je kunt inloggen i.p.v. twee. Je laat jouw server dus extra werk doen (hash uitrekenen kost rekenkracht!) zodat je makkelijker gehackt kan worden...
P.S. bij de gegeven strings zat de salt er natuurlijk al bij ;)
Gewijzigd op 27/12/2011 09:50:21 door Mark L