[C#] Password hashing

[tha_crazy]

Ben voor iemand een nieuwe site aan het bouwen maar deze zal een register/login gaan gebruiken.
Oke, nu dat is nieuw!

Maar nu, zoekende naar de beste oplossing ben ik ondertussen al een hoop tegengekomen, maar voor niks kan ik echt vinden wat nu echt past bij deze klant.
Ga ik SHA256 gebruiken, of toch PBKDF2.
En dan natuurlijk nog hier en daar een SALT.

De laatste keer dat ik een login systeem heb gebouwd, dateert nog uit de tijd dat MD5 nog veilig werd geacht, dus dat is al een poosje geleden.

Iemand hier die mij een duwtje in de rug kan geven zodat ik de verkeerde bomen in het bos kan kappen en zo toch de juiste oplossing kan implementeren?

[glrfndl]

Als je zelf wat wilt maken kun je eens kijken naar de crypto helpers: MSDN: Crypto.HashPassword Method (System.Web.Helpers)

En anders kun je wellicht gebruik maken van een (simple) membership provider: MSDN: Managing Users by Using Membership en MSDN: SimpleMembershipProvider Class (WebMatrix.WebData)

[tha_crazy]

glrfndl schreef op maandag 09 september 2013 @ 23:10:
Als je zelf wat wilt maken kun je eens kijken naar de crypto helpers: MSDN: Crypto.HashPassword Method (System.Web.Helpers)

En anders kun je wellicht gebruik maken van een (simple) membership provider: MSDN: Managing Users by Using Membership en MSDN: SimpleMembershipProvider Class (WebMatrix.WebData)

Naja, zelf iets schrijven zal niet snel gebeuren, maar zoek wel de beste implementatie.
Mijn persoonlijke mening is altijd: zorg dat je informatie niet vrijkomt.

De methode die ik nu snel heb geimplementeerd is deze: http://www.obviex.com/samples/hash.aspx
Deze kan per direct ook weer vervangen worden natuurlijk, maar voor testen is deze momenteel prima in orde.

Voor mij is het van zaak, als de beheerder niet goed met zijn zaakjes om gaat, dan wil ik alsnog dat de wachtwoorden niet zomaar op straat komen te liggen.

[begintmeta]

Waarom geen bcrypt?

[pedorus]

De code die je linkt is een verschrikking, System.Random() gebruiken in een cryptografische context is niet ok (valt hier mee, maar zeer onhandig om voor variabele saltlengte van soms slechts 4 te gaan), net als dat de algoritmes niet ok zijn deze context, omdat ze veel te snel kunnen worden uitgevoerd op moderne processors. Gebruik BCrypt of PBKDF2. BCrypt heeft als voordeel dat het iets trager is als het gekraakt wordt op grafische kaarten, PBKDF2 heeft als voordeel dat het al in het .NET framework zit. Als je de NSA vertrouwd, of juist paranoïde wordt van ze, dan is het interessant om te weten dat de NSA PBKDF2 aanraadt.

[ Voor 7% gewijzigd door pedorus op 09-09-2013 23:51 ]

[tha_crazy]

Nu inderdaad overgestapt naar de crypto method van .net.
Huidige code:

C#:

string randPass = Membership.GeneratePassword(8,0);
            string hashedPass = Crypto.HashPassword(randPass);

[HMS]

Gewoon BCrypt of SCrypt gebruiken. Bijna alle andere hash algoritmes zijn niet geschikt voor het beveiligen van wachtwoorden. De simpele reden is: ze zijn te snel.

Als je een checksum van een paar gigabyte aan data wil berekenen is dit fijn, zodra je een wachtwoord wil beveiligen niet. De aanvaller kan in dat geval miljoenen of miljarden combinaties per seconde berekenen.
Dat kan bij BCrypt of SCrypt tegengegaan worden door de 'work factor' omhoog te gooien. Hierdoor kunnen er maar tientallen of honderden hashes per seconde berekend worden.

Ook kunnen algoritmes als BCrypt en SCrypt niet (efficient) op een GPU gedaan worden. Omdat tegenwoordig GPU hash cracking veel sneller is dan bijv. rainbow tables is het handig om je hier tegen te wapenen (zie bijv. HashCat).

Aangezien gebruikers 90% van de tijd gewoon zwakke wachtwoorden hebben, is het handig dat je hun via een traag hash algoritme de kans geeft om toch hun wachtwoord te wijzigen mocht de user db gestolen worden.

[RobIII]

Wat betreft BCrypt:

quote: http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html

I write this post because I've noticed a sort of "JUST USE BCRYPT" cargo cult (thanks Coda Hale!) This is absolutely the wrong attitude to have about cryptography.

Trek er je eigen conclusie(s) uit; ik zeg niet dat je 't niet moet gebruiken; ik vond 't gewoon een interessant stukje, vooral de quote. Maar pak ook even de comments mee die erbij staan.

Ook hier een interessant stukje:

quote: http://security.stackexch...assword-storage/6415#6415

While I recommend bcrypt, I still follow NIST in that if you implement PBKDF2 and use it properly (with a "high" iteration count), then it is quite probable that password storage is no longer the worst of your security issues.

Wat natuurlijk een waarheid als een koe is; ergens moet je de lijn trekken en "move on".

[ Voor 49% gewijzigd door RobIII op 10-09-2013 11:31 ]

[tha_crazy]

HMS schreef op dinsdag 10 september 2013 @ 10:59:
Gewoon BCrypt of SCrypt gebruiken. Bijna alle andere hash algoritmes zijn niet geschikt voor het beveiligen van wachtwoorden. De simpele reden is: ze zijn te snel.

Als je een checksum van een paar gigabyte aan data wil berekenen is dit fijn, zodra je een wachtwoord wil beveiligen niet. De aanvaller kan in dat geval miljoenen of miljarden combinaties per seconde berekenen.
Dat kan bij BCrypt of SCrypt tegengegaan worden door de 'work factor' omhoog te gooien. Hierdoor kunnen er maar tientallen of honderden hashes per seconde berekend worden.

Ook kunnen algoritmes als BCrypt en SCrypt niet (efficient) op een GPU gedaan worden. Omdat tegenwoordig GPU hash cracking veel sneller is dan bijv. rainbow tables is het handig om je hier tegen te wapenen (zie bijv. HashCat).

Aangezien gebruikers 90% van de tijd gewoon zwakke wachtwoorden hebben, is het handig dat je hun via een traag hash algoritme de kans geeft om toch hun wachtwoord te wijzigen mocht de user db gestolen worden.

Oke, dan zou ik dat even moeten gaan onderzoeken vanavond.
Zie dat de functie die ik nu gebruik, die in .net zit gebruikt maakt van PBKDF2.
Maar deze is dan dus in dit geval ook snel te kraken?

Engigzins zwakke wachtwoorden zijn natuurlijk af te vangen door een gebruiker een minimum aantal karakters te geven met hoofdletters en specialte tekens.
Hoewel je dan bij MijnW8woord? ook wel weer in de gemakzone komt.

Ik gebruik momenteel de Membership.GeneratePassword methode en hierbij geeft hij zelf al een nette random password, voorbeeldje: )5CRenW-
Deze zou ik dan natuurlijk ook nog kunnen opvoeren aan lengte en de gebruiker niet de mogelijkheid geven om deze te wijzigen, echter komt dan ook weer de gebruiksvriendelijkheid in het gevaar.

[RobIII]

tha_crazy schreef op dinsdag 10 september 2013 @ 11:24:
Engigzins zwakke wachtwoorden zijn natuurlijk af te vangen door een gebruiker een minimum aantal karakters te geven met hoofdletters en specialte tekens.

Dan is deze ook verplicht leesvoer

[tha_crazy]

RobIII schreef op dinsdag 10 september 2013 @ 11:26:
[...]

Dan is deze ook verplicht leesvoer

Die staat standaard in mijn geheugen gegrift gelukkig

[ZpAz]

RobIII schreef op dinsdag 10 september 2013 @ 11:26:
[...]

Dan is deze ook verplicht leesvoer

True, maar met dictionary attacks die x aantal woorden achter elkaar plakken haal je die ook onderuit.

[pedorus]

Nee, het idee is dat een woord 2^11 entropy toevoegt. Je kiest dus random woorden uit een dictionary van 2^11=2048 woorden. 4 willekeurige woorden achter elkaar geven dan (2^11)^4=2^44 entropie. En het is natuurlijk nog een stuk hoger als je niet weet dat dit wachtwoordschema gebruikt is voor het genereren van een wachtwoord.

HMS schreef op dinsdag 10 september 2013 @ 10:59:
Gewoon BCrypt of SCrypt gebruiken. Bijna alle andere hash algoritmes zijn niet geschikt voor het beveiligen van wachtwoorden. De simpele reden is: ze zijn te snel.

Dit roept 2 vragen op:
-Wat is er mis met PBKDF2 mits voldoende iteraties worden gebruikt?
-Hoe weet je of SCrypt goed werkt? Waarom een 'bleeding edge' algoritme?

[Phyxion]

RobIII schreef op dinsdag 10 september 2013 @ 11:26:
[...]

Dan is deze ook verplicht leesvoer

Heb je wat aan bij banken waar ze maximale lengtes hanteren van 12 tekens

[Cloud]

ZpAz schreef op dinsdag 10 september 2013 @ 12:41:
[...]

True, maar met dictionary attacks die x aantal woorden achter elkaar plakken haal je die ook onderuit.

Alles is uiteindelijk onderuit te halen, gegeven genoeg tijd. Maar als je kijkt naar de toegenomen lengte (entropie!) zijn die wachtwoorden bestaande uit meerdere woorden toch echt veel sterker. Zelfs al zijn het allemaal woorden die in een simpele/kleine dictionary voorkomen.

Phyxion schreef op dinsdag 10 september 2013 @ 15:06:
[...]

Heb je wat aan bij banken waar ze maximale lengtes hanteren van 12 tekens

Dat zou inderdaad verboden moeten worden.

[HMS]

pedorus schreef op dinsdag 10 september 2013 @ 14:55:

[...]

Dit roept 2 vragen op:
-Wat is er mis met PBKDF2 mits voldoende iteraties worden gebruikt?
-Hoe weet je of SCrypt goed werkt? Waarom een 'bleeding edge' algoritme?

Opzich is er niks mis met PBKDF, maar m.i. is die niet bedoeld voor het beveiligen van wachtwoorden. Wel als je van een wachtwoord naar een encryptie sleutel wil gaan. PBKDF staat namelijk voor Password Based Key Derivation Function, dus van een wachtwoord naar een AES sleutel bijvoorbeeld. De 2 staat voor versie 2 die iets flexibeler is in zijn output, 1 kon alleen een vaste output size geven als ik mij niet vergis.

Dat wil niet zeggen dat PBKDF met voldoende iteraties niet werkt, het is in ieder geval al beter dan één SHA hash berekenen.


Ik zit even de paper over SCrypt te lezen (http://www.tarsnap.com/scrypt/scrypt.pdf) en ik zie dat dit niet helemaal een juiste redenering is. SCrypt adverteert zichzelf ook als een key derivation function. Sterker nog het lijkt gewoon gebruik te maken van PBKDF2. Maar door extra geheugen te gebruiken voor de berekeningen is het een stuk duurder om specialistische hardware te bouwen wat efficient SCrypt kan kraken.

Tja en dan natuurlijk de vraag, hoe weet je zeker dat BCrypt en SCrypt cryptografisch veilig zijn. Simpel: dat weet je niet. In mindere mate geldt dit natuurlijk ook voor de SHA familie van hashes, die zijn ook niet gegarandeerd veilig. Het voordeel is wel dat die vrij streng beoordeeld zijn op hun cryptografische veiligheid.

Naar mijn weten zijn er geen aanvallen op zowel BCrypt als SCrypt die hun cryptografische 'strength' aantasten. Mocht dit in de toekomst wel zo blijken te zijn, dan zul je moeten migreren naar een ander hash algoritme. Maar dit geldt ook voor de SHA hashes natuurlijk, zodra die gekraakt worden is het ook tijd om te switchen.

Cloud schreef op dinsdag 10 september 2013 @ 15:09:
[...]

Alles is uiteindelijk onderuit te halen, gegeven genoeg tijd. Maar als je kijkt naar de toegenomen lengte (entropie!) zijn die wachtwoorden bestaande uit meerdere woorden toch echt veel sterker. Zelfs al zijn het allemaal woorden die in een simpele/kleine dictionary voorkomen.

Dit is dus niet waar. De lengte van een wachtwoord bepaald maar gedeeltelijk de entropy die het heeft. De volgorde van letters is in taal voorspelbaarder dan random, dus extra lengte betekend niet automatisch +n bits entropy.

Uiteraard als je alleen naar bruteforce aanvallen kijkt, dan wel. Maar tegenwoordig is een goede password corpus en dictionary goed genoeg om binnen een week ongeveer 90% van de wachtwoorden te kraken.

Zie ook: http://arstechnica.com/se...at-out-of-your-passwords/

[ Voor 8% gewijzigd door HMS op 10-09-2013 15:33 ]

[johnkeates]

Gebruik PBKDF2, je kan daar zelf je hashing en evt. encryptie mee uitkiezen. Wel rekening houden met het feit dat het dan wel een erg goed idee wordt om meer metadata op te slaan over het wachtwoord, zodat je bijv. evt. upgrades je seamless de wachtwoorden bij een logon ook kan upgraden. Dat is ook meteen een van de grote voordelen van PBKDF2, je kan gewoon sterkere encryptie gebruiken zonder alles te hoeven herschrijven.

[Cloud]

HMS schreef op dinsdag 10 september 2013 @ 15:14:
[...]
Dit is dus niet waar. De lengte van een wachtwoord bepaald maar gedeeltelijk de entropy die het heeft. De volgorde van letters is in taal voorspelbaarder dan random, dus extra lengte betekend niet automatisch +n bits entropy.

Het is wellicht kort door de bocht maar het is absoluut een goede manier om een lang wachtwoord te maken dat goed te onthouden valt.

Uiteraard als je alleen naar bruteforce aanvallen kijkt, dan wel. Maar tegenwoordig is een goede password corpus en dictionary goed genoeg om binnen een week ongeveer 90% van de wachtwoorden te kraken.

Het wachtwoord alleen is niet de beveiliging natuurlijk Als het opgeslagen wordt met MD5 of een andere snelle hash heb je daar geen bal aan. Dan geloof ik wel dat binnen een week tijd 90% gekraakt kan worden. Sterke wachtwoorden zijn alleen sterk als ze goed opgeslagen worden, dus met het juiste algoritme zoals PBKDF2.

[ Voor 5% gewijzigd door Cloud op 10-09-2013 15:54 ]

[pedorus]

Cloud schreef op dinsdag 10 september 2013 @ 15:53:
Sterke wachtwoorden zijn alleen sterk als ze goed opgeslagen worden, dus met het juiste algoritme zoals PBKDF2.

Lijkt me conceptueel niet helemaal correct. Zelfs met MD5, dus zeg maar zo'n 1.000.000 keer sneller dan bcrypt (traagste in die test), is een echt sterk wachtwoord voldoende beveiligd. Als de entropie 100.0000.000 keer groter is dan een zwakker wachtwoord dat met bcrypt is opgeslagen, dan is het sterke wachtwoord nog steeds een 100x lastiger te kraken. Vandaar dat bcrypt vooral helpt bij het beschermen van 'niet zo goede' maar ook niet extreem slechte wachtwoorden. Dat is natuurlijk wel de grootste categorie, vandaar dat bcrypt een goed idee is.

[Cloud]

Oké misschien theoretisch niet nee, met zo'n enorm groot verschil in entropie. Maar ik vraag me af of zo'n verschil in entropie voor zal komen in de praktijk Het verschil in snelheid illustreert natuurlijk wel waarom het zo verschrikkelijk belangrijk is een goede (langzame!) hash methode te gebruiken, zoals bcrypt/PBKDF2.

[DrDelete]

tha_crazy schreef op maandag 09 september 2013 @ 22:49:
Ben voor iemand een nieuwe site aan het bouwen maar deze zal een register/login gaan gebruiken.

Aha, website. Ik raad je aan om ASP.NET membership provider te gebruiken, zit alles in om je username/passwords veilig te registreren.