pbkdf2 - Een veilige manier om wachtwoorden op te slaan
Door Chris -, 15 jaar geleden, 17.692x bekeken
pbkdf2, de afkorting van Password-Based Key Derivation Function 2, is een methode om een wachtwoord met salt meerdere keren in een "derived key" te berekenen.
Aanroepen van deze functie is zeer simpel:
pbkdf2($password, $salt, $algorithm = 'sha512', $count = 20000, $key_length = 128, $raw_output = false);
De variabelen spreken voor zich. Het aantal iterations staat standaard op 20000 in combinatie met een key length van 128. Een sterk wachtwoord en een goede hash, zal de wachtwoorden van je klanten een stuk veiliger maken.
Tijdens een bruteforce poging met een vooraf gegeven salt, was de maximale snelheid voor het maken van een wachtwoord 0.04-0.06 seconde. Het duurt een flink aantal uur om een wachtwoord van enkele karakters te kraken, laat staan wachtwoorden van 10+ karakters.
Gesponsorde koppelingen
PHP script bestanden
Er zijn 12 reacties op 'Pbkdf2 een veilige manier om wachtwoorden op te slaan'
0 
-0 
-0
Het coderen met bcrypt duurt langer en is dus beter voor bruteforce aanvallen. (Natuurlijk afhankelijk van het aantal rounds)
Ook geeft deze functie steeds dezelfde hash. Hierdoor zijn aanvallen met rainbow tables ook een mogelijkheid.
Beter bcrypt gebruiken dus!
Ook geeft deze functie steeds dezelfde hash. Hierdoor zijn aanvallen met rainbow tables ook een mogelijkheid.
Beter bcrypt gebruiken dus!
0 -0
-0
De VeeWee, het maken van een rainbow table duurt zéér lang. Zeker als je gebruik maakt van een fatsoenlijk aantal karakters. Probeer 't maar eens, dan zul je zien dat het zo goed als onmogelijk is als je 10+ karakters heb.
0 -0
-0
Je hebt lijsten met de meest voorkomende wachtwoorden. Stel dat je de 1000 meets voorkomende wachtwoorden encrypteerd en dus 0.05s per wachtwoord nodig hebt. Dan heb je iets van een 50s nodig voor deze lijst om te zetten naar hashes.
Stel dat iemand aan uw database komt en weet dat je dit algoritme gebruikt. Dan komt hij hoogstwaarschijnlijk een hoog percentage van de gebruikers hun wachtwoorden te weten. Vermits er zeer veel mensen makkelijke en veel gebruikte wachtwoorden gebruiken!
Stel dat iemand aan uw database komt en weet dat je dit algoritme gebruikt. Dan komt hij hoogstwaarschijnlijk een hoog percentage van de gebruikers hun wachtwoorden te weten. Vermits er zeer veel mensen makkelijke en veel gebruikte wachtwoorden gebruiken!
0 -0
-0
Daarom is het gebruik van een goede Salt ook noodzakelijk. Zonder Salt is het al niet haalbaar, en als je zelf je beveiliging scherper zet door een wachtwoord van minimaal 8 karakters te eisen, met daarbij ook nog minimaal 1 cijfer en 1 speciale karakter, wordt het al een stuk lastiger ;-)
Hij moet het aantal iteraties weten, de key-length en de salt..
Hij moet het aantal iteraties weten, de key-length en de salt..
0 -0
-0
Ik zocht al enkele dagen naar een goede manier om wachtwoorden gecodeerd op te slaan in de database.
Ik ga denk ik deze gebruiken van Chris.
Want hij doet ook site checks, of ze wel veilig zijn.
Deze manier zal dus wel veilig zijn :)
Alleen even wat extra uitleg nodig:
$password: Dat is het wachtwoord van de gebruiker.
$salt: Die variable moet ik zelf aanmaken. Welke lengte moet een salt ongeveer hebben?
$count = 20000: Ik snap niet wat de count doet?
$key_length = 128: Die snap ik ook niet helemaal.
Mag je de count zelf bepalen? En de key length ook?
Tevens, een dynamische pepper eraan toevoegen? Of is dat over kill?
Ik ga trouwens nu het script even lokaal draaien en wat proberen.
Dem
Ik ga denk ik deze gebruiken van Chris.
Want hij doet ook site checks, of ze wel veilig zijn.
Deze manier zal dus wel veilig zijn :)
Alleen even wat extra uitleg nodig:
$password: Dat is het wachtwoord van de gebruiker.
$salt: Die variable moet ik zelf aanmaken. Welke lengte moet een salt ongeveer hebben?
$count = 20000: Ik snap niet wat de count doet?
$key_length = 128: Die snap ik ook niet helemaal.
Mag je de count zelf bepalen? En de key length ook?
Tevens, een dynamische pepper eraan toevoegen? Of is dat over kill?
Ik ga trouwens nu het script even lokaal draaien en wat proberen.
Dem
0 -0
-0
Nog een klein vraagje, ik heb nu dit uitgeprobeerd.
Hoe lang wordt het wachtwoord (gecordeerd)?
Ik heb even wat uitgeprobeerd en telkens 172.
En als ik nu voorbeeld $raw_output = true zet, dan krijg ik heel andere tekens, allemaal speciale.
Is het dan veiliger om dit true te zetten om op te slaan?
Hoe lang wordt het wachtwoord (gecordeerd)?
Ik heb even wat uitgeprobeerd en telkens 172.
En als ik nu voorbeeld $raw_output = true zet, dan krijg ik heel andere tekens, allemaal speciale.
Is het dan veiliger om dit true te zetten om op te slaan?
0 -0
-0
Chris schreef: Hij moet het aantal iteraties weten, de key-length en de salt..
Maar dat is dus niet waar.
Want dat weet jouw PHP-script wel.
Een brute-forcer gebruikt gewoon jouw inlogformulier. En dan ga jij (of eigenlijk: jouw php-code) het wachtwoord '123456' gewoon hashen. Nergens voor nodig dus.
Pas als hij een dump van je database heeft weten te ontvangen is een rainbowtabel handig. Maar zodra hij in je database kan, waarom zou hij dan niet in je php-bestanden kunnen?
Omdat je database open staat? Dat moet je (ook) voorkomen.
Maar dat is dus niet waar.
Want dat weet jouw PHP-script wel.
Een brute-forcer gebruikt gewoon jouw inlogformulier. En dan ga jij (of eigenlijk: jouw php-code) het wachtwoord '123456' gewoon hashen. Nergens voor nodig dus.
Pas als hij een dump van je database heeft weten te ontvangen is een rainbowtabel handig. Maar zodra hij in je database kan, waarom zou hij dan niet in je php-bestanden kunnen?
Omdat je database open staat? Dat moet je (ook) voorkomen.
0 -0
-0
@Eddy, dat los je op d.m.v. een (slimme) anti-bruteforce. Mijn anti-bruteforce is op een dusdanige manier opgebouwd, dat het 5 pogingen per gebruiker toelaat. Niet te doen dus.
0 -0
-0
Hashing is alleen nuttig tegen aanvallers die je db hebben. Dan zal je beveiliging je niet redden.
0 -0
-0
Bruteforce
Ik denk dat je het beste voor bruteforce aanvallen, zoals Chris al zei... een block inzet van bijvoorbeeld 5 à 15 minuten wanneer het wachtwoord X aantal keren verkeerd is.
Natuurlijk ongeacht het IP-adres omdat dat toch te omzeilen is. Gebruik hiervoor zeker ook geen sessies want die zijn natuurlijk ook nutteloos.
Eventueel zou je wel een optie kunnen maken om de bruteforce block op te geven via een email of een captcha (die natuurlijk moeilijk te lezen is voor OCR's...).
Hashing
Ik zou zoals ook al eens gezegd is altijd een salt gebruiken met dan een hasher (bcrypt, pbkdf2 -> hierboven...) en dan kom je al heel ver wanneer een hacker de database in handen heeft.
Want tegen dat je een wachtwoord van minstens 6 tekens met minimaal 1 hoofdletter, 1 kleine letter en een cijfer + 3 andere tekens kraakt denk ik toch dat het al even zal duren want je moet eerst ook nog uitzoeken hoe de wachtwoorden gehasht zijn (+ salt & pepper).
Want met een gehasht wachtwoord met eventueel een salt en pepper zal een rainbow tabel nutteloos zijn.
Ik denk dat je het beste voor bruteforce aanvallen, zoals Chris al zei... een block inzet van bijvoorbeeld 5 à 15 minuten wanneer het wachtwoord X aantal keren verkeerd is.
Natuurlijk ongeacht het IP-adres omdat dat toch te omzeilen is. Gebruik hiervoor zeker ook geen sessies want die zijn natuurlijk ook nutteloos.
Eventueel zou je wel een optie kunnen maken om de bruteforce block op te geven via een email of een captcha (die natuurlijk moeilijk te lezen is voor OCR's...).
Hashing
Ik zou zoals ook al eens gezegd is altijd een salt gebruiken met dan een hasher (bcrypt, pbkdf2 -> hierboven...) en dan kom je al heel ver wanneer een hacker de database in handen heeft.
Want tegen dat je een wachtwoord van minstens 6 tekens met minimaal 1 hoofdletter, 1 kleine letter en een cijfer + 3 andere tekens kraakt denk ik toch dat het al even zal duren want je moet eerst ook nog uitzoeken hoe de wachtwoorden gehasht zijn (+ salt & pepper).
Want met een gehasht wachtwoord met eventueel een salt en pepper zal een rainbow tabel nutteloos zijn.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu