Password hashing met salt

[Morax]

Naar aanleiding van de reacties op nieuws: LinkedIn: wachtwoorden zijn nu gesalt

In de reacties kom ik twee verschillende manieren tegen om password hashing met een salt toe te passen, en ik vraag me af welke nu de juiste of betere methode is.

Voor beide methodes geldt: De salt is een random string die verschilt per gebruiker, en die in de kolom "salt" is opgeslagen in dezelfde tabel waar de hash staat.

Beide methodes lijken qua veiligheid op elkaar, een collision vinden heeft voor beide methodes geen nut, en rainbow tables zullen minder effectief zijn door de salt.

Zit er echter een verschil in de daadwerkelijke veiligheid van beide methodes die ik over het heeft zie, waardoor de ene methode veiliger is dan de ander?

Methode 1:
Een deel van de gebruikers noemt de volgende methode:

PHP:

$password = 'mijnwachtwoord';
$salt = '1234';

$hash = sha1($password . $salt);

Kortom: de salt wordt toegevoegd aan het password, en dat geheel wordt gehasht.

Methode 2:
Dan de andere methode:

PHP:

$password = 'mijnwachtwoord';
$salt = '1234';

$hash = sha1(sha1($password) . $salt);

In dit geval wordt het password gehasht, waarna de salt aan de hash wordt toegevoegd, en het geheel nogmaals wordt gehasht.

Edit:
Een verschil wat ik me net besef:
Met de tweede manier is het "makkelijker" om de originele string van de tweede hash te vinden, je weet immers de lengte van de die string: de lengte van een sha1 hash (40 tekens) + de lengte van de hash. Hiermeer verklein je de mogelijkheden die je moet proberen enorm.

[ Voor 11% gewijzigd door Morax op 13-06-2012 14:57 ]

[Ventieldopje]

Gewoon "normaal" salten dus, om het moeilijker te maken zou je een vaste salt en een "dynamische" salt moeten gebruiken. Die dynamische salt genereer je voor elk wachtwoord dat je opslaat en kun je gewoon in een veld in de zelfde regel opslaan.

Op die manier (correct me if i'm wrong) als de aanvallers je database in handen krijgen hebben ze nog maar 1 van de 2 salts en zouden ze dus ook toegang tot je code moeten hebben of sterker nog toegang tot buiten je wwwroot om de vaste salt te pakken te krijgen.

[Kalentum]

Als je geen zin hebt om dit wiel opnieuw uit te vinden kun je ook een library gebruiken: http://www.openwall.com/phpass/

The preferred (most secure) hashing method supported by phpass is the OpenBSD-style Blowfish-based bcrypt, also supported with our public domain crypt_blowfish package (for C applications), and known in PHP as CRYPT_BLOWFISH, with a fallback to BSDI-style extended DES-based hashes, known in PHP as CRYPT_EXT_DES, and a last resort fallback to MD5-based salted and variable iteration count password hashes implemented in phpass itself (also referred to as portable hashes).

Werkt erg goed en wordt ook gebruikt in enkele open source projecten.

[RayNbow]

Ventieldopje schreef op woensdag 13 juni 2012 @ 15:37:
en zouden ze dus ook toegang tot je code moeten hebben

Wikipedia: Security through obscurity, ergo, ga er vanuit dat aanvallers weten hoe je systeem werkt.

[Soultaker]

In PHP is er eigenlijk geen enkele reden om niet de standaardfunctie crypt te gebruiken.

Gebruiksvoorbeeld (aangezien PHP-developers nogal van het copy/pasten van code lijken te zijn):

PHP:

// Wachtwoord en salt had je al:
$password = 'mijnwachtwoord';
$salt = '1234';

// Genereer een salted hash. $hashed kun je opslaan in je database.
$hashed = crypt($password, '$5$'.$salt);
echo '$hashed=', $hashed, "\n";

// Een wachtwoord checken met salt kan door de hashed string mee te geven aan crypt()
// (die dan dezelfde salt gebruikt) en te checken dat het resultaat gelijk is aan $hashed:
echo $password, ': ', (crypt($password, $hashed) == $hashed ? "goed" : "fout"), "\n";
$password = 'anderwachtwoord';
echo $password, ': ', (crypt($password, $hashed) == $hashed ? "goed" : "fout"), "\n";

[ Voor 19% gewijzigd door Soultaker op 13-06-2012 16:26 ]

[Zeebonk]

Hoe weet crypt de salt van een willekeurige hashed string? Heeft crypt state? Vind het er maar obscuur uit zien en de documentatie zegt er natuurlijk weer niks over.

[ Voor 5% gewijzigd door Zeebonk op 13-06-2012 18:05 ]

[CoolGamer]

Dit is een interessant artikel wat uitlegt waarom een salt alleen niet genoeg is. Dan nog blijft het wachtwoord redelijk snel te kraken met de hardware van tegenwoordig. Dus als je een goede beveiliging wilt zal je er toch wat meer in moeten verdiepen.

[NMe]

Een reden voor de tweede methode is dat het een mogelijkheid toevoegt om, zonder HTTPS, een gehasht wachtwoord over de lijn te gooien. Kun je de eerste hash in javascript doen en vervolgens aan de serverkant salten en nogmaals hashen.

[Soultaker]

Zeebonk schreef op woensdag 13 juni 2012 @ 18:04:
Hoe weet crypt de salt van een willekeurige hashed string? Heeft crypt state? Vind het er maar obscuur uit zien en de documentatie zegt er natuurlijk weer niks over.

De uitvoer van crypt() is een ASCII string van de vorm: $5$1234$NZfHEPGdHstWeiAZ8PPTIujHjV6IWXUyDf20KWdikx3. Hierbij geeft 5 het gebruikte algoritme aan (iterated SHA-256, zoals beschreven bij Ulrich Drepper, afgekeken van Poul-Henning Kamp, natuurlijk). De string 1234 tussen dollartekens was de gebruikte salt, en de rest van de string is de (base-64 encoded) hash van het wachtwoord.

Bij het gegeneren van hashes leest crypt() de parameters uit de "salt" string maar de daadwerkelijke password hash wordt natuurlijk genegeerd. crypt() zelf is dus gewoon stateless; de benodigde state zit in de uitvoer gecodeerd.

Dit staat allemaal ook in de PHP documentatie toegelicht, maar het blijkt maar weer dat PHP-developers nooit documentatie lezen (en dan denken: ik vind het maar obscuur, laat ik maar zelf een ondoordachte halfbakken codering verzinnen.)

[Anoniem: 180352]

NMe schreef op woensdag 13 juni 2012 @ 18:09:
Een reden voor de tweede methode is dat het een mogelijkheid toevoegt om, zonder HTTPS, een gehasht wachtwoord over de lijn te gooien. Kun je de eerste hash in javascript doen en vervolgens aan de serverkant salten en nogmaals hashen.

In dat geval is je hash het geheim geworden. De hash is dan de facto even veel waard als het originele wachtwoord. Dat is dus volstrekt zinloos.

Bij authenticatie via wachtwoorden zijn er 2 beveiligingsproblemen die volledig losstaan van elkaar:

1. Het opslaan van het geheim aan de serverzijde op een veilige manier. Gebruik hiervoor hashing met salts, bv. in PHP met crypt().
2. Het transporteren van het geheim van de gebruiker tot bij de server. Hiervoor is encryptie noodzakelijk, dus HTTPS. Client-side hashen helpt hierbij geen mallemoer.

Anno 2012 is het niet gebruiken van hashing met salts én HTTPS eigenlijk onvergeeflijk. Wat kost een SSL-certificaat nu nog En alsjeblieft, knutsel niet zelf iets in elkaar. Als niet-professional heb je met bijna-zekerheid zwakheden in je implementatie (denk aan side-channel attacks, ...)

Je kan HTTPS wel laten vallen als je gebruik maakt van een challenge-response authenticatieschema. Maar dan zit je vaak weer met probleem 1.

[Soultaker]

Anoniem: 180352 schreef op woensdag 13 juni 2012 @ 18:48:
In dat geval is je hash het geheim geworden. De hash is dan de facto even veel waard als het originele wachtwoord. Dat is dus volstrekt zinloos.

Waarom is dat zinloos? Het lijkt me dat methode 2 minstens zo goed is al methode 1?

Overigens is het in z'n algemeenheid beter om een HMAC te gebruiken in plaats van methode 1 óf methode 2. De salt is dan de key waarmee de hash gecodeerd wordt.

Anoniem: 180352 schreef op woensdag 13 juni 2012 @ 18:48:
Je kan HTTPS wel laten vallen als je gebruik maakt van een challenge-response authenticatieschema. Maar dan zit je vaak weer met probleem 1.

Nee hoor; je kunt prima salted hashes gebruiken, want de salt mag gewoon openbaar zijn.

Het echte probleem is dat plaintext verbindingen vatbaar zijn voor man-in-the-middle attacks: als je op JavaScript vertrouwt (zoals Tweakers.net ook doet) om het wachtwoord te versleutelen dan kan een attacker die JavaScript code aanpassen. Dat is nog steeds iets beter dan plaintext authenticatie (omdat het vereist dat de gebruiker niet alleen kan afluisteren, maar ook de communicatie can beïnvloeden) maar een SSL verbinding is inderdaad strict beter.

[ Voor 42% gewijzigd door Soultaker op 13-06-2012 18:56 ]

[Anoniem: 180352]

Soultaker schreef op woensdag 13 juni 2012 @ 18:52:
[...]

Waarom is dat zinloos? Het lijkt me dat methode 2 minstens zo goed is al methode 1?

Dat in zinloos om "zonder HTTPS, een gehasht wachtwoord over de lijn te gooien" (dixit NMe). Client-side hashen vervangt SSL niet, zoals lijkt gesuggereerd te worden. Een beveiligde verbinding is gewoon noodzakelijk om MITM te vermijden.

Los daarvan ben ik het met je eens dat methode 2 strikt genomen "iets minder slecht" is

[Zeebonk]

Soultaker schreef op woensdag 13 juni 2012 @ 18:47:
De uitvoer van crypt() is een ASCII string van de vorm: $5$1234$NZfHEPGdHstWeiAZ8PPTIujHjV6IWXUyDf20KWdikx3. Hierbij geeft 5 het gebruikte algoritme aan (iterated SHA-256, zoals beschreven bij Ulrich Drepper, afgekeken van Poul-Henning Kamp, natuurlijk). De string 1234 tussen dollartekens was de gebruikte salt, en de rest van de string is de (base-64 encoded) hash van het wachtwoord.

-knip-

Dit staat allemaal ook in de PHP documentatie toegelicht, maar het blijkt maar weer dat PHP-developers nooit documentatie lezen (en dan denken: ik vind het maar obscuur, laat ik maar zelf een ondoordachte halfbakken codering verzinnen.)

Je uitleg is duidelijk, maar dat vond ik hier niet terug. Dan nog vind ik het raar dat als er een encrypted string als salt mee word gegeven die functie toevallig begrijpt dat het niet puur de hash is maar ook nog een zootje meta informatie bij zich heeft en het daarom anders behandeld. Dat haal ik al helemaal niet uit die documentantie.

[NMe]

Anoniem: 180352 schreef op woensdag 13 juni 2012 @ 19:17:
[...]

Dat in zinloos om "zonder HTTPS, een gehasht wachtwoord over de lijn te gooien" (dixit NMe). Client-side hashen vervangt SSL niet, zoals lijkt gesuggereerd te worden. Een beveiligde verbinding is gewoon noodzakelijk om MITM te vermijden.

Ik heb ook niet gezegd dat het SSL vervangt, ik heb gezegd dat het een klein stukje extra bescherming biedt als er om wat voor reden dan ook geen SSL mogelijk is.

[Kwistnix]

Is de hele salt discussie tot op zekere hoogte niet irrelevant op dit moment? Het hele principe is er op gebaseerd dat een buitgemaakte hash niet eenvoudig tot een plain text wachtwoord te herleiden is via een rainbow table look-up. Dus effectief zal de aanvaller terug moeten vallen op een "domme" brute force aanpak. Echter, met de rekenkracht van hedendaagse hardware en de relatief lage kosten daarvan, wordt dat niet een steeds realistische aanpak voor niet-adaptieve hash algoritmen als SHA-1, of desnoods de SHA-2 set? Ik denk dat algoritmen als pbkdf2, bcrypt en scrypt, die key strengthening toepassen en ontworpen zijn om het hardware-voordeel tegen te werken, nu al een betere optie zijn. Of zelfs noodzakelijk?

[Soultaker]

Ja, liefst natuurlijk salting + iterative hashing (aka key strengthening). Vandaar dat ik crypt() met zinnige parameters voorstelde.

De salt is absoluut niet irrelevant; bij de LinkedIn database waren meer dan een miljoen hashes gelekt. Een salt had het kraken van een willekeurig wachtwoord in zo'n database dus ongeveer een miljoen keer zo moeilijk gemaakt (in de praktijk iets minder, maar toch). Vergelijk je dat met iterated hashing, waarbij PHP standaard 5000 rounds doet, dan is de veiligheidswinst die je krijgt van het toevoegen van een salt dus orden van grootte groter dan van iterative hashing alleen (maar onthoud: ik bepleit dat je beide moet doen!)

Natuurlijk is iets als scrypt (wat er vooral op gericht is om hardware-implementaties van hashfuncties lastiger/duurder te maken) nóg beter maar vergeleken met de uitgangssituaties (unsalted non-iterated hashes) is élke verbetering welkom natuurlijk.

Eigenlijk denk ik dat de échte boodschap aan gebruikers is dat je niet kunt vertrouwen op derde partijen, en je dus óf zelf moet zorgen voor wachtwoorden met voldoende entropie (en dan bedoelen we niet zes tot acht letters-of-cijfers), óf een tool als KeePass of (veel beter natuurlijk ) mijn eigen AutoPass moet gebruiken om te zorgen dat de wachtwoorden die je naar een derde partij stuuurt voldoende entropie hebben om een brute-force aanval te weerstaan.

[ Voor 38% gewijzigd door Soultaker op 14-06-2012 00:54 ]

[Gomez12]

Simpel gezegd :
- Geen 1
- Geen 2
Maar optie 3 pakken : of een standaard library functie die dit afhandelt (zoals Soultaker voorstelt) of ssl gebruiken of een combinatie van die 2.

Je wilt gewoon niet met wachtwoorden lower-level functies (zoals sha1) gebruiken zonder gedegen cryptografische kennis zodat je je openingsvraag niet hoeft te stellen. Gebruik gewoon een higher-level functie die tried and tested is.

[crisp]

Soultaker schreef op woensdag 13 juni 2012 @ 18:52:
[...]
als je op JavaScript vertrouwt (zoals Tweakers.net ook doet) om het wachtwoord te versleutelen
[...]

offtopic:
Dat doen we al een tijdje niet meer hoor; inloggen gaat nu gewoon via https

[CyBeR]

NMe schreef op woensdag 13 juni 2012 @ 19:48:
[...]

Ik heb ook niet gezegd dat het SSL vervangt, ik heb gezegd dat het een klein stukje extra bescherming biedt als er om wat voor reden dan ook geen SSL mogelijk is.

Het biedt voor jouw site geen extra bescherming. Als ik de bezoeker afluister heb ik zijn password hash en die kan ik gewoon naar jou sturen alsof er niets aan de hand is.

Wel weet ik dan niet (zonder rainbow table, wat te doen is want je salt pas aan de serverkant) het originele wachtwoord. Dus je zou kunnen zeggen dat je andere sites beschermt.

[Soultaker]

CyBeR schreef op donderdag 14 juni 2012 @ 01:35:
Het biedt voor jouw site geen extra bescherming. Als ik de bezoeker afluister heb ik zijn password hash en die kan ik gewoon naar jou sturen alsof er niets aan de hand is.

Ook dat is onzin, want zoals ik al zei kun je op basis van een hash ook een challenge-response protocol implementeren. Je stuurt bijvoorbeeld de salt en een nonce naar de client, en je vraagt de client om hmac(hmac(password, salt), nonce) terug te sturen.

Als je een challenge en een (correcte!) response onderschept, dan kun je weliswaar het password bruteforcen, maar als het password sterk genoeg is lukt dat niet, en met de intercepted data alleen kun je niet inloggen. Die situatie is dus hetzelfde als challenge-response authentication met het plaintext wachtwoord, behalve dat de server het oorspronkelijke wachtwoord niet op hoeft te slaan. Dat is pure winst, want als de site dan z'n password database lekt liggen de oorspronkelijke wachtwoorden niet op straat (maar in dat geval kun je wél inloggen met de gelekte hashes, natuurlijk).

[CyBeR]

Soultaker schreef op donderdag 14 juni 2012 @ 02:21:
[...]

Ook dat is onzin, want zoals ik al zei kun je op basis van een hash ook een challenge-response protocol implementeren.

Ja, dat kan. Maar daar hadden we 't niet over.

Dat is pure winst, want als de site dan z'n password database lekt liggen de oorspronkelijke wachtwoorden niet op straat (maar in dat geval kun je wél inloggen met de gelekte hashes, natuurlijk).

Dat is dus géén pure winst. Sterker nog, je hebt je probleem erger gemaakt dan wanneer je gewoon salted hashes opsloeg en meer niet. Ook hier bescherm je andere sites ten koste van je eigen, want je hebt de hash een password-equivalent gemaakt. Waarmee je in kunt loggen als je de hash weet. En dan ben je, voor wat jouw site betreft, niet beter af dan het opslaan van plain text wachtwoorden.

[ Voor 51% gewijzigd door CyBeR op 14-06-2012 02:24 ]

[Soultaker]

CyBeR schreef op donderdag 14 juni 2012 @ 02:22:
Ja, dat kan. Maar daar hadden we 't niet over.

Daar hadden we het wél over. NMe zei letterlijk “als er om wat voor reden dan ook geen SSL mogelijk is.” en dat stond ook in jouw quote.

In die situatie is hash-based authenticatie strict beter dan plaintext authenticatie. Het biedt bescherming tegen derden die de communicatie wel kunnen afluisteren maar niet kunnen beïnvloeden.

[ValHallASW]

Soultaker schreef op donderdag 14 juni 2012 @ 03:49:
In die situatie is hash-based authenticatie strict beter dan plaintext authenticatie. Het biedt bescherming tegen derden die de communicatie wel kunnen afluisteren maar niet kunnen beïnvloeden.

Ja/nee. Niet voor je eigen site, wel voor de gebruiker. Cookies kunnen immers ook afgeluisterd worden, maar het wachtwoord inderdaad niet meer.


Mbt salting & hashing: doe wat je aanvaller doet, gebruik CUDA!

[Anoniem: 146875]

Je kunt ook salt en pepper gebruiken om het nog veiliger te maken, de pepper is dan eens soort salt maar verschilt per wachtwoord. Als je het wachtwoord niet weet kun je nog wel de salt weten maar niet de pepper.

PHP:

$pass = "secret123";
$salt = "23!sdf@XX-=987wQ##"; // moeilijke random string
$pepper = strlen($pass)
 + substr($pass, 0, 5) 
 + strlen($pass); // $pepper = 9secre9

$encrypted = '';
for(i = 0; i<1000; i++) $encrypted = sha1($pepper + $pass + $encrypted + $salt + $pepper);

Twee aantekeningen:
- je cookies natuurlijk secure zetten zodat ze alleen via ssl verstuurd worden.
- Ipv sha1 kun je beter sha512 oid gebruiken

[cpf_]

Even vermelden dat er best wel wat mensjes zijn die daarover al gedacht hebben:

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

Alhoewel het pepper idee er niet instaat, is het inderdaad niet ver om nog een extra salt toe te voegen bij iedere iteratie.

Also: Ik denk dat ze op zoek zijn naar ideetjes en mensen die hierin willen meewerken

[CyBeR]

Soultaker schreef op donderdag 14 juni 2012 @ 03:49:
[...]

Daar hadden we het wél over. NMe zei letterlijk “als er om wat voor reden dan ook geen SSL mogelijk is.” en dat stond ook in jouw quote.

SSL en Challenge-Response hebben niks met elkaar te maken. En feit is dat jij de eerste was die Challenge-Response noemde. Daar reageerde ik dus niet op.

In die situatie is hash-based authenticatie strict beter dan plaintext authenticatie. Het biedt bescherming tegen derden die de communicatie wel kunnen afluisteren maar niet kunnen beïnvloeden.

Het biedt zonder C/R alleen bescherming voor andere websites die niet op dezelfde manier werken. De communicatie met een publieke webserver is prima te replayen vanaf je eigen machine. Je hebt alleen de hash nodig. Met C/R los je dat inderdaad op want je luistert nooit de goede hash af.

Overigens is TLS wel de beste oplossing natuurlijk.

[Grijze Vos]

CyBeR schreef op donderdag 14 juni 2012 @ 11:30:
[...]


SSL en Challenge-Response hebben niks met elkaar te maken. En feit is dat jij de eerste was die Challenge-Response noemde. Daar reageerde ik dus niet op.

De SSL handshake heeft best veel weg van een C-R hoor.

[ReenL]

Anoniem: 146875 schreef op donderdag 14 juni 2012 @ 10:01:
Je kunt ook salt en pepper gebruiken om het nog veiliger te maken, de pepper is dan eens soort salt maar verschilt per wachtwoord. Als je het wachtwoord niet weet kun je nog wel de salt weten maar niet de pepper.

Zinlozer als dit pepper idee kan bijna niet. Lengte van een string + eerste 5 tekens kost bijna geen extra rekenkracht. Als je het iemand moeilijker wilt maken, gebruik dan meer iteraties, maar ga niet een of ander nieuw algoritme verzinnen. Ook hoeft een salt niet random te zijn, gooi gewoon de username erbij.

Wat heeft de salt ermee te maken dat je, je wachtwoord vergeten bent? Wat zijn je bronnen voor deze ideeën en waarom heb je het gevoel dat je dit moet delen? Je zorgt alleen maar dat andere mensen ook deze fouten gaan maken.

[CyBeR]

ReenL schreef op vrijdag 15 juni 2012 @ 22:04:
[...]


Zinlozer als dit pepper idee kan bijna niet. Lengte van een string + eerste 5 tekens kost bijna geen extra rekenkracht. Als je het iemand moeilijker wilt maken, gebruik dan meer iteraties, maar ga niet een of ander nieuw algoritme verzinnen. Ook hoeft een salt niet random te zijn, gooi gewoon de username erbij.

Hoewel de username op zich inderdaad een prima salt is, heeft dat het praktische effect dat als je dat niet expliciet opslaat (en er dus van uit gaat username == salt) dat je wachtwoord niet meer werkt als je username verandert.

[alwinuzz]

Over de PHP crypt() functie, ik lees dit:

It also only uses the first eight characters of str, so longer strings that start with the same eight characters will generate the same result (when the same salt is used).

Begrijp ik nou goed dat ie alleen de eerste 8 tekens van het wachtwoord gebruikt? Dus "BOTERHAMmen" is hetzelfde als "BOTERHAMworst" ?

[Thralas]

Ja, maar dit geldt enkel voor de DES-variant.

[bwerg]

CyBeR schreef op vrijdag 15 juni 2012 @ 22:18:
[...]


Hoewel de username op zich inderdaad een prima salt is, heeft dat het praktische effect dat als je dat niet expliciet opslaat (en er dus van uit gaat username == salt) dat je wachtwoord niet meer werkt als je username verandert.

Of je moet het zo maken dat je bij het wijzigen van je username, ook je wachtwoord moet invullen.

Maar goed, je kan het ook zo maken dat het níet omslachtig is, natuurlijk.

[Anoniem: 146875]

ReenL schreef op vrijdag 15 juni 2012 @ 22:04:
[...]


Zinlozer als dit pepper idee kan bijna niet. Lengte van een string + eerste 5 tekens kost bijna geen extra rekenkracht. Als je het iemand moeilijker wilt maken, gebruik dan meer iteraties, maar ga niet een of ander nieuw algoritme verzinnen. Ook hoeft een salt niet random te zijn, gooi gewoon de username erbij.

Wat heeft de salt ermee te maken dat je, je wachtwoord vergeten bent? Wat zijn je bronnen voor deze ideeën en waarom heb je het gevoel dat je dit moet delen? Je zorgt alleen maar dat andere mensen ook deze fouten gaan maken.

Volgens mij snap je niet helemaal hoe je een wachtwoord veilig moet opslaan. De pepper maakt reverse engineren een stuk moeilijker. Doordat je het wachtwoord aanvult met een salt moet je het salt ergens opslaan; als je vervolgens het encryptie algoritme weet en de salt (die je toch ergens moet vastleggen) dan heb je aan 1 set rainbow tabellen genoeg om alle wachtwoorden uit de database te kraken.

De pepper is niet afhankelijk van de gebruikersnaam (die je waarschijnlijk plaintext vastlegt) maar van het wachtwoord en verschilt dus voor ieder wachtwoord. Elk wachtwoord heeft dus zijn eigen rainbow tabel nodig.

Snap je het nog?

[Soultaker]

NOFI, maar volgens mij snap jij niet wat een salt is.

Anoniem: 146875 schreef op zaterdag 16 juni 2012 @ 20:36:
De pepper is niet afhankelijk van de gebruikersnaam (die je waarschijnlijk plaintext vastlegt) maar van het wachtwoord en verschilt dus voor ieder wachtwoord.

Dit is met een (goede) salt ook al zo.

Dus wat voegt die "pepper" dan nog toe? Als je brute-force aan het kraken bent kun je net zo makkelijk die pepper erbij berekenen (aangenomen dat het algoritme waarmee je die afleidt bekend is — geen security through obscurity).

[Anoniem: 146875]

Hierboven werd gesproken over een statisch salt of een salt afhankelijk van een plaintext gebruikersnaam. Het enige wat het pepper doet is het gebruik van rainbow tabellen onmogelijk maken en daarnaast is de pepper onbekend, zelfs als je het salt al weet. Als je gaat brute-forcen maakt het inderdaad niet uit.

[Soultaker]

Een statische salt kiezen is natuurlijk compleet zinloos. De oplossing is dan om een random salt te kiezen, niet om iets nieuws te verzinnen.

En nu ik er over nadenk, vermoed ik dat jouw pepersysteem juist wél vatbaar voor aanvallen met een rainbow table!

[Anoniem: 146875]

Ben benieuwd waarom het vatbaar is. Ik ben altijd in voor verbetering van dit soort zaken.

[Soultaker]

Omdat, als de salt constant is, je feitelijk een unsalted hashfunctie gebruikt. Dat die hashfunctie veel complexer geïmplementeerd is, maakt niet fundamenteel uit voor het berekenen van de rainbow table.

Je hashfunctie is gedefinieerd als:

PHP:

function my_hash($pass)
{
    $salt = "23!sdf@XX-=987wQ##"; // moeilijke random string

    $pepper = strlen($pass)
     + substr($pass, 0, 5) 
     + strlen($pass); // $pepper = 9secre9

    $encrypted = '';
    for(i = 0; i<1000; i++) $encrypted = sha1($pepper + $pass + $encrypted + $salt + $pepper);
    return $encrypted;
}

Da's gewoon een deterministische, unsalted hash function. Daar kun je dus een rainbow table voor berekenen.

[ Voor 57% gewijzigd door Soultaker op 16-06-2012 22:29 ]

[Anoniem: 146875]

Daarvoor voeg je dus de pepper toe. Jij gebruikt iets randoms in de salt, ik neem een statisch salt en noem het random gedeelte de pepper. Rainbow tabel gaat niet werken omdat de pepper voor ieder wachtwoord anders is.

[RayNbow]

Anoniem: 146875 schreef op zondag 17 juni 2012 @ 09:04:
[...] ik neem een statisch salt en noem het random gedeelte de pepper.

Jouw pepper is niet random:

Anoniem: 146875 schreef op donderdag 14 juni 2012 @ 10:01:

PHP:

$pass = "secret123";
$salt = "23!sdf@XX-=987wQ##"; // moeilijke random string
$pepper = strlen($pass)
 + substr($pass, 0, 5) 
 + strlen($pass); // $pepper = 9secre9

$encrypted = '';
for(i = 0; i<1000; i++) $encrypted = sha1($pepper + $pass + $encrypted + $salt + $pepper);

Hierin is overduidelijk te zien dat jouw pepper niets anders is dan een transformatie van het wachtwoord, zoals Soultaker al zei.

Voor de duidelijkheid, het hele idee van salted hashes is dat je de volgende twee functies hebt:

code:

generateHash : (RandGen x Password) -> (Salt x Hash)
checkPassword : (Salt x Hash x Password) -> Bool

Of herschreven met SaltedHash = Salt x Hash:

code:

generateHash : (RandGen x Password) -> (SaltedHash)
checkPassword : (SaltedHash x Password) -> Bool

Hierbij moet het zo zijn dat als de input RandGen (de gebruikte random number generator), de output SaltedHash en de definities van de twee functies generateHash en checkPassword publiekelijk bekend zijn, je niet het geheime wachtwoord kunt achterhalen.

[xos]

Best wel een leuk topic dit

Dat pepper idee lijkt mij ook niet echt veel toevoegen, het idee van een salt is dat het genereren van een rainbow table niet praktisch is en daar helpt het toevoegen van een pepper op deze manier niet bij. Een conversie functie moet discreet zijn en bij deze aanpak is de input elke keer hetzelfde. Anders gezegd, 2 gebruikers met hetzelfde wachtwoord hebben met deze aanpak dezelfde password hash waardoor het opstellen van een rainbow tabel een mogelijke strategie is.

Het pepper idee triggerde mij wel, momenteel maak ik gebruik van key stretching met een unieke salt per wachtwoord, per omgeving (OTAP) om wachtwoord op te slaan. Probleem wat ik hierbij heb is dat de iteratie count een trade off is tussen performance (cpu cycles) en veiligheid. Eigenlijk zou ik de iteratie count groter willen nemen dan deze nu staat. Alleen wil niemand betalen voor de extra cpu cycles of een dedicated crypto hardware module om de iteratie count te verhogen. Dus daarmee is de discussie snel voorbij.

Nu er betaalbare hardware is in de vorm van gpu's wordt een brute force methode een steeds reëler scenario. Ik weet helaas niks van gpu programmeren maar wat ik tijdens een presentatie begreep is een gpu in staat is om een operatie op verschillende blokken data in parallel uit te voeren. Veel hash functies werken met een set aan registers waar een serie operaties op worden uitgevoerd en zijn dus erg snel te berekenen met een gpu.

Wat ik mij afvraag, wordt door de input van de iteratie at te laten hangen van de vorige iteratie de cache strategie van een gpu om zeep geholpen? Het hash algoritme is nog steeds snel maar er moet tussendoor iets extra worden gedaan waar de gpu op moet wachten.

Dus iets als dit:

code:

passwd = ...
salt = gensalt()
hash = hash(salt || passwd || salt)

for (i in range(1, n))
   tmp = substr(hash, 0, 5 + (i % max_len-5))
   result = hash(tmp || passwd || tmp)

return salt, result

[alwinuzz]

Thralas schreef op zaterdag 16 juni 2012 @ 04:03:
Ja, maar dit geldt enkel voor de DES-variant.

Oh ja, je hebt gelijk. Jammer dat DES dan weer de default manier is.

[CyBeR]

Anoniem: 146875 schreef op zondag 17 juni 2012 @ 09:04:
Daarvoor voeg je dus de pepper toe. Jij gebruikt iets randoms in de salt, ik neem een statisch salt en noem het random gedeelte de pepper. Rainbow tabel gaat niet werken omdat de pepper voor ieder wachtwoord anders is.

Ten eerste, en zoals gezegd, een statische salt is compleet kansloos. Met een enkele rainbowtabel ben je er dan, en die is zo gemaakt.

Ten tweede, wat jij hier pepper noemt is gewoon wat de rest van de wereld een salt noemt. De rest van de wereld ziet namelijk in dat een statisch stuk data bij een wachtwoord voegen geen nut heeft en geeft dat dus ook geen naam. Het heeft geen nut in het voorkomen van kraakbaarheid via rainbow tables en het heeft ook geen nut om te voorkomen dat twee personenen met hetzelfde wachtwoord (wat prima toevallig mogelijk is) dezelfde hash krijgen, waarna je uit dat gegeven kunt afleiden dat hun wachtwoord identiek is.

[Soultaker]

xos schreef op zondag 17 juni 2012 @ 11:30:
Nu er betaalbare hardware is in de vorm van gpu's wordt een brute force methode een steeds reëler scenario. Ik weet helaas niks van gpu programmeren maar wat ik tijdens een presentatie begreep is een gpu in staat is om een operatie op verschillende blokken data in parallel uit te voeren. Veel hash functies werken met een set aan registers waar een serie operaties op worden uitgevoerd en zijn dus erg snel te berekenen met een gpu.

In principe kan een moderne CPU ook best aardig de executie van instructies overlappen, zelfs beter dan de GPU. De kracht van een GPU zit 'm er vooral in dat 'ie dezelfde instructies op heel veel data items tegelijk kan uitvoeren (SIMD) of onafhankelijke programma's op meer verschillende cores kan uitvoeren (waar Nvidia's Fermi architectuur voor ontworpen is).

Wat ik mij afvraag, wordt door de input van de iteratie at te laten hangen van de vorige iteratie de cache strategie van een gpu om zeep geholpen?

Ik weet niet wat voor caching je van de GPU verwacht, maar iteratief hashing is al slecht paralleliseerbaar, omdat elke volgende iteratie van het resultaat van de vorige. Met een GPU kun je dus niet sneller een SHA-1 hash berekenen dan met een CPU. Maar wél kun je een heleboel hashes tegelijk berekenen.

Daarom zal een hacker altijd meer aan een GPU hebben dan een loginserver. (Nog los van het feit dat GPUs in servers nog steeds extreem zeldzaam zijn.)

[PiepPiep]

Volgens mij is de pepper onzin.
Of je nou van 8 letterig password wat dus 26^8 combinaties 'password' 'password5passw5' maakt of 'ppaasssswwoorrdd', het blijven in alle gevallen 26^8 combinaties.

Wat ik trouwens nog niet gelezen heb in deze thread is dat het slim is om de salt te veranderen als het password veranderd wordt.
Dus 'password1' 'randomsaltperpassword1' wordt na wijzigen van password 'password2' 'randomsaltperpassword2'.

Ik zou zelf trouwens als salt iets van een guid gebruiken denk ik, maar ik heb hier nog nooit iets mee hoeven doen.

[RayNbow]

PiepPiep schreef op maandag 18 juni 2012 @ 10:23:
Wat ik trouwens nog niet gelezen heb in deze thread is dat het slim is om de salt te veranderen als het password veranderd wordt.

Zie het type van de functie generateHash in RayNbow in "Password hashing met salt"?

[PiepPiep]

RayNbow schreef op maandag 18 juni 2012 @ 10:35:
[...]


Zie het type van de functie generateHash in RayNbow in "Password hashing met salt"?

Ah, ik kan goed over dingen heen lezen

[RobIII]

PiepPiep schreef op maandag 18 juni 2012 @ 10:23:
Ik zou zelf trouwens als salt iets van een guid gebruiken denk ik, maar ik heb hier nog nooit iets mee hoeven doen.

GUIDs are designed to be unique, not random
Een GUID is nog altijd vele malen beter dan een 1-char "pepper" en dat soort ongein, maar een GUID is niet voor dit soort doeleinden bedoeld.

Zie ook:
GUID Guide, part one
GUID guide, part two
GUID guide, part three

[ValHallASW]

RobIII schreef op dinsdag 19 juni 2012 @ 10:51:
[...]
GUIDs are designed to be unique, not random
Een GUID is nog altijd vele malen beter dan een 1-char "pepper" en dat soort ongein, maar een GUID is niet voor dit soort doeleinden bedoeld.

Hoezo niet? Waarom is een random (=niet te voorspellen) salt beter dan een unieke salt?

[ Voor 20% gewijzigd door ValHallASW op 19-06-2012 11:34 ]

[RobIII]

ValHallASW schreef op dinsdag 19 juni 2012 @ 11:31:
Hoezo niet? Waarom is een random (=niet te voorspellen) salt beter dan een unieke salt?

Omdat een GUID (niet altijd) random is (en dus voorspelbaar)
Überhaupt het artikel gelezen waar ik naar link?

Even kort door de bocht: stel je hebt de "createdate" van een account in 'tzelfde record zitten. Op basis daarvan kun je de salt dan "voorspellen" -> salt == useless.

[ Voor 24% gewijzigd door RobIII op 19-06-2012 11:36 ]

[ValHallASW]

RobIII schreef op dinsdag 19 juni 2012 @ 11:33:
Omdat een GUID (niet altijd) random is

Dat weet ik. Mijn vraag is dan ook een andere: waarom is het relevant dat een GUID niet-random is zolang deze maar uniek is. Voor zover ik weet is het doel een unieke salt, en een random salt is een manier op dat te bereiken.

Even kort door de bocht: stel je hebt de "createdate" van een account in 'tzelfde record zitten. Op basis daarvan kun je de salt dan "voorspellen" -> salt == useless.

Ten eerste is die niet globaal uniek (en dus geen GUID); verder: waarom is het relevant dat je de salt kunt voorspellen? Ja, dan kan je proberen een rainbow table proberen te maken, maar dat is niet sneller dan het berekenen nadat je salt+hash beiden hebt.

[ Voor 36% gewijzigd door ValHallASW op 19-06-2012 11:37 ]

[ACM]

RobIII schreef op dinsdag 19 juni 2012 @ 11:33:
Even kort door de bocht: stel je hebt de "createdate" van een account in 'tzelfde record zitten. Op basis daarvan kun je de salt dan "voorspellen" -> salt == useless.

Doorgaans staat de salt plain text bij het wachtwoord... dus waarom is dat een probleem?

[RobIII]

Ja, goeiemorgen. Ben nog niet helemaal wakker vandaag
Jullie hebben helemaal gelijk en my bad...

[ Voor 31% gewijzigd door RobIII op 19-06-2012 11:47 ]

[Barryvdh]

Maar om even een lang verhaal kort te maken, zijn er beperkingen aan het simpelweg gebruiken van de crypt functie van php, met een random salt generator? Want in het geval van een database hack, is de salt plaintext te lezen, maar dat wil dus zeggen dat je nog steeds niks hebt aan een rainbowtable en dus een brute force aanval moet doen per wachtwoord. Voegt het hebben van een geheime (hardcoded in je config) extra salt nog iets toe? Want het zorgt ook weer voor moelijkheden, zoals het niet plaintext opslaan van je salt en dus moeilijker te controleren.

En welk algoritme raad je dan aan, blowfish of SHA512 en hoeveel rounds? Jammer dat php.net geen actuele recommendations doet, en een werkend veilig voorbeeld (inclusief salt generator), of gewoon default een salt genereert op basis van je algoritme)

[ACM]

De extra salt maakt het in theorie lastiger om je uitgelekte database te kraken. Maar als je een bekend wachtwoord in de lijst hebt (stel je weet dat pietje wachtwoord 'test123' heeft), dan is het dan natuurlijk vrij eenvoudig om juist de extra salt als onbekende tekst te beschouwen en die dan te beschouwen als het te kraken wachtwoord.

Het is dus sowieso zinvol om een stevige hash te gebruiken. In principe is het handig om 'het beste wat er momenteel is' te nemen, want je wil ze bij voorkeur natuurlijk voor meerdere jaren veilig houden. Afhankelijk van de bron die je leest zal je voor sha512 tussen de 5000 en 50.000 iteraties zien, wij doen 10.000.

Overigens is het verstandig om erop te letten dat je niet domweg sha512(sha512(....sha512($pass . $salt))); doet. Want daarmee verzwak je het algoritme (sha512 kan daar wel veel beter tegen dan md5 en sha1) door steeds minder keyspace te hebben een beetje mee. Vziw doet php's CRYPT_SHA512 dat intern overigens goed.
Blowfish is een op zich prima alternatief, maar ik vond het allemaal een stuk minder duidelijk in gebruik.

Dat is overigens sowieso de reden dat we geen php crypt gebruiken, maar domweg een php-implementatie van PBKDF2. Dat houdt het ook wat eenvoudiger om later vanuit een andere omgeving tegen dezelfde data te praten.

[PiepPiep]

ACM schreef op dinsdag 19 juni 2012 @ 13:11:
Overigens is het verstandig om erop te letten dat je niet domweg sha512(sha512(....sha512($pass . $salt))); doet. Want daarmee verzwak je het algoritme (sha512 kan daar wel veel beter tegen dan md5 en sha1) door steeds minder keyspace te hebben een beetje mee.

Waarom is dit niet goed en hoe moet je het dan doen?
Als dit niet veilig zou zijn en je elke iteratie iets aan entropie kwijt raakt dan zou je collisions kunnen vinden?

[Barryvdh]

Het gebruik van blowfish en sha512 is met crypt toch hetzelfde?
En welke implementatie gebruik je dan (of is dat geen standaard implementatie, zoals hier in de comments http://php.net/manual/en/function.hash-hmac.php)

[Cartman!]

ACM schreef op dinsdag 19 juni 2012 @ 13:11:
Dat is overigens sowieso de reden dat we geen php crypt gebruiken, maar domweg een php-implementatie van PBKDF2. Dat houdt het ook wat eenvoudiger om later vanuit een andere omgeving tegen dezelfde data te praten.

Momenteel gebruik ik ook PBKDF2 in PHP als methode om een hash van het wachtwoord te berekenen met de username als salt. Het enige dat ik ervan begreep is dat PBKDF2 opzich zelf eigenlijk bedoeld is om keys te genereren vanuit iemand zijn wachtwoord (key derivation) maar dat je het ook prima kan gebruiken om het wachtwoord zelf mee te hashen. Ik zat te denken om over te stappen op bcrypt omdat die er meer specifiek voor bedoeld is. Hoewel je volgens mij met beide methodes al niet meer interessant bent voor een hacker, er zijn over t algemeen slechter beveiligde databases te 'verkrijgen'.

[Marcks]

PiepPiep schreef op dinsdag 19 juni 2012 @ 14:08:
[...]

Waarom is dit niet goed en hoe moet je het dan doen?
Als dit niet veilig zou zijn en je elke iteratie iets aan entropie kwijt raakt dan zou je collisions kunnen vinden?

Hoe onveilig het is, durf ik niet te zeggen, maar je raakt inderdaad entropie kwijt. Als elke combinatie van 512 bits een unieke hash oplevert, is er niets aan de hand, maar die kans is voor vrijwel alle algoritmes nihil. Er zullen collisions tussen zitten en voor elke twee inputs (bijv. A en die dezelfde hash opleveren, is er een andere hash (C) die niet meer gemaakt kan worden. De lijst combinaties die aanvankelijk 2⁵¹² entries lang was, is dus kleiner geworden. Voer je nog een iteratie uit, dan ontbreekt niet alleen C, maar ook sha512(C), of een andere entry indien dit toevallig zelf ook weer een collision was. Bovendien kunnen twee unieke entries inmiddels gehasht zijn naar A en B, welke bij een derde iteratie dus gaan colliden.

Het is in theorie zelfs mogelijk dat alle 2⁵¹² entries uiteindelijk dezelfde hash opleveren.

[Soultaker]

Daarom doe je typisch iets als:

code:

hash = ""
for each round:
    hash = sha512(password + hash)

Hoewel slimme implementaties als bcrypt nog veel uitgebreidere key expansion hebben.

Ik vraag me trouwens af of het mogelijk is een cyclische hashfunctie te maken die ook cryptografisch secure is. Die zou dan vrij van collissions moeten zijn (mits de invoer even groot is als de uitvoer, natuurlijk!)

[ Voor 4% gewijzigd door Soultaker op 19-06-2012 18:11 ]

[Marcks]

Dat helpt toch niet? Als er in een iteratie collisions optreden, wordt de ruimte hoe dan ook kleiner en hij kan zonder bron van entropie niet groter worden. Ik gebruikte sha512 als voorbeeld, maar het argument gaat op voor elke hashfunctie, dus ook de arbitraire functie h(x), gedefinieerd als h(x) = sha512(password + x).

Er bestaan trouwens wel cyclische functies zonder collisions welke in de cryptografie worden toegepast, maar naar mijn weten niet om wachtwoorden te hashen. f(x) = g^x mod p, bijvoorbeeld, welke met een invoer in de range van één tot priemgetal p en de juiste keuze voor de generator g, voor elke input een unieke waarde oplevert in hetzelfde bereik.

[Soultaker]

Marcks schreef op dinsdag 19 juni 2012 @ 19:17:
Dat helpt toch niet? Als er in een iteratie collisions optreden, wordt de ruimte hoe dan ook kleiner en hij kan zonder bron van entropie niet groter worden.

Dat helpt wel. Als de verzameling van mogelijke wachtwoorden A is en de verzameling van uitkomsten van de hashfunctie daarop B is (dus B = { hash(x) for x in A }) dan kan het zijn dat B kleiner is dan A (kort: |B| <= |A|); dat is het probleem wat je noemt.

Maar de verzameling C = { hash(x) + x for x in A } heeft gegarandeerd dezelfde grootte als A (als de uitvoer van de hash-functie een vaste grootte heeft) omdat zelfs bij collisions het laatste deel nog uniek is.

BIjvoorbeeld als de hashfunctie één cijfer geeft, en hash("foo") = hash("bar") = 7, dan heb je daar inderdaad een collision. Maar waarschijnlijk is hash("7foo") niet gelijk aan hash("7bar"). En zelfs als dat wel zo is, dan heeft de volgende iteratie waarschijnlijk geen collision. Dit alles onder aanname dat een cryptografische hashfunctie te beschouwen is als een random functie.

Zo voorkom je dus tussentijdse collisions waardoor de het verlies van entropie na een miljoen keer hashen niet groter is dan het verlies na één keer hashen.

Er bestaan trouwens wel cyclische functies zonder collisions welke in de cryptografie worden toegepast, maar naar mijn weten niet om wachtwoorden te hashen. f(x) = gx mod p, bijvoorbeeld, welke met een invoer in de range van nul tot priemgetal p en de juiste keuze voor de generator g, voor elke input een unieke waarde oplevert in hetzelfde bereik.

Interessant! Voorwaarde voor cryptografisch gebruik van zo'n hashfunctie is natuurlijk wel dat alle cycles voldoende lang zijn (idealiter is het één grote cycle) of dat korte cycles dusdanig zeldzaam zijn dat je ze praktisch gezien niet kunt vinden.

[ Voor 19% gewijzigd door Soultaker op 20-06-2012 00:46 ]

[bwerg]

Soultaker schreef op woensdag 20 juni 2012 @ 00:44:
Interessant! Voorwaarde voor cryptografisch gebruik van zo'n hashfunctie is natuurlijk wel dat alle cycles voldoende lang zijn (idealiter is het één grote cycle) of dat korte cycles dusdanig zeldzaam zijn dat je ze praktisch gezien niet kunt vinden.

Het voorbeeld wat Marcks gaf kan inderdaad één grote cykel geven.

Als we dan toch een vraag&antwoord-topic over hashes hebben: waarom wordt één hashfunctie gewoon 1000 keer geïtereerd, in plaats van dat er gebruik wordt gemaakt van een 1000 keer zo zware functie? Dan heb je het gezeur van vermindering van entropie niet.

[Barryvdh]

Misschien omdat het dan niet schaalbaar is? Of je niet makkelijk de functie zwaarder kan maken in de toekomst.

[RayNbow]

Het idee is dat je kunt instellen hoe rekenintensief de uiteindelijke hashfunctie moet zijn. (edit: spuit11)

[ Voor 10% gewijzigd door RayNbow op 20-06-2012 10:47 ]

[bwerg]

Ja, maar zoals gezegd heeft een 1000-maal herhaalde hash-functie nadelen die je niet zou hebben met één goede, zwaardere hash-functie (meer collisions). Aangezien er toch behoefte is aan meer rekenintensieve hash-functies (d.m.v. 1000 keer herhalen) zou ik zeggen dat daar ook wel een 'native' functie zonder itereren voor bedacht zou zijn. In plaats van 1000, 2000 of 10.000 iteraties krijg je dan 1, 2 of 10 iteraties, ook prima schaalbaar als je toch in die hogere ordes zit.

Maar misschien zijn de nadelen van hash-functies itereren wel behoorlijk overdreven, dan valt het te begrijpen.

[ Voor 14% gewijzigd door bwerg op 20-06-2012 11:43 ]

[jbdeiman]

Wat mij vooral opvalt is dat er vaak een vaste positie voor een Salt of Pepper wordt gebruikt. Waarom is dat? Het is eenvoudiger te maken, maar als je in een wachtwoord verplicht stelt (dat kan je als minimale beveiligingseis stellen) er speciale tekens in moeten komen en je doet hetzelfde met de hash (ook speciale tekens) die je evt wel genereert op basis van een aantal gegevens (waaronder bijv het gebruikers_id, om deze uniek te maken), dan is het volgens mij behoorlijk veilig.
Postitie kan je ook "bepalen" op basis van een aantal gegevens, waardoor positie van de salt en/ of pepper ook kan wisselen.

Bijv:

Wachtwoord A!5p128P
Salt: A*S1s

Als je dan A!5pA*S1s128P gaat hashen dan wens ik iedereen veel succes met het terug redeneren van het wachtwoord. Hashen is leuk, maar het grootste probleem is de eenvoud van de wachtwoorden die worden gebruikt.


Wachtwoord =

[ACM]

Cartman! schreef op dinsdag 19 juni 2012 @ 14:34:
Het enige dat ik ervan begreep is dat PBKDF2 opzich zelf eigenlijk bedoeld is om keys te genereren vanuit iemand zijn wachtwoord (key derivation) maar dat je het ook prima kan gebruiken om het wachtwoord zelf mee te hashen.

Een wachtwoordhash is domweg een derived key. Alleen heeft PBKDF2 nog als toevoeging dat ie in principe ook een resultaat van willekeurige lengte kan aanleveren, ook als dat langer is dan de output van de hashfunctie. Je zou dus een key kunnen genereren van 65 bytes met zowel sha1 als sha512 als onderliggende methode. 't Is uiteraard een beetje 'zonde' om slechts 1 byte van de 64 die je van het 2e blok uit de interne pbkdf2-routine krijgt te gebruiken, maar voor de beveiliging is het niet eens zo heel relevant.

bwerg schreef op woensdag 20 juni 2012 @ 11:00:
Ja, maar zoals gezegd heeft een 1000-maal herhaalde hash-functie nadelen die je niet zou hebben met één goede, zwaardere hash-functie (meer collisions). Aangezien er toch behoefte is aan meer rekenintensieve hash-functies (d.m.v. 1000 keer herhalen) zou ik zeggen dat daar ook wel een 'native' functie zonder itereren voor bedacht zou zijn. In plaats van 1000, 2000 of 10.000 iteraties krijg je dan 1, 2 of 10 iteraties, ook prima schaalbaar als je toch in die hogere ordes zit.

Het is heel moeilijk om een duurdere functie te maken zonder intern domweg met een vergelijkbare key-stretchingroutine te werken.

Maar misschien zijn de nadelen van hash-functies itereren wel behoorlijk overdreven, dan valt het te begrijpen.

Het is niet overdreven. Maar het is relatief eenvoudig op te lossen, bijvoorbeeld zoals Soultaker dat doet of ingewikkelder (zoals in bcrypt of in PBKDF2):

code:

U1 = PRF(P,S || INT_msb(i))
U2 = PRF(P,U1)
...
Uc = PRF(P,Uc-1)

En dat uiteindelijk samengevoegd wordt als resultaat:

code:

F(P,S,c,i) = U1 ^ U2 ^ ... ^ Uc

Oftewel zoiets:

code:

for each iteration
  hash = hash xor hashFunction(password, hash)

Op die manier is elke iteratie opnieuw afhankelijk van het ingevoerde wachtwoord en wordt bovendien ook elke iteratie heel sterk samen gevoegd met de vorige iteraties. Overigens was o.a. de manier waarop vorige iteraties meegenomen werden een van de verbeteringen van PKBDF2 ten op zichte van versie 1, daarvoor gebeurde het meer in lijn met wat Soultaker noemt.

[bwerg]

ACM schreef op woensdag 20 juni 2012 @ 12:41:
Het is heel moeilijk om een duurdere functie te maken zonder intern domweg met een vergelijkbare key-stretchingroutine te werken.

Nee, ik snap dat de gemiddelde devver dat niet even in elkaar improviseert. Maar steeds als er onderzoek wordt gedaan naar nieuwe hashing-algoritmes is een van de eisen dat het zo snel mogelijk te berekenen is. Ik vraag me af waarom er nooit onderzoek wordt gedaan naar een wat zwaarder hashing-algoritme, aangezien dat dus ook zijn toepassingen heeft.

[PiepPiep]

Marcks schreef op dinsdag 19 juni 2012 @ 14:50:
[...]


Hoe onveilig het is, durf ik niet te zeggen, maar je raakt inderdaad entropie kwijt. Als elke combinatie van 512 bits een unieke hash oplevert, is er niets aan de hand, maar die kans is voor vrijwel alle algoritmes nihil. Er zullen collisions tussen zitten en voor elke twee inputs (bijv. A en die dezelfde hash opleveren, is er een andere hash (C) die niet meer gemaakt kan worden. De lijst combinaties die aanvankelijk 2⁵¹² entries lang was, is dus kleiner geworden. Voer je nog een iteratie uit, dan ontbreekt niet alleen C, maar ook sha512(C), of een andere entry indien dit toevallig zelf ook weer een collision was. Bovendien kunnen twee unieke entries inmiddels gehasht zijn naar A en B, welke bij een derde iteratie dus gaan colliden.

Het is in theorie zelfs mogelijk dat alle 2⁵¹² entries uiteindelijk dezelfde hash opleveren.

Dat vraag ik me dus af, volgens mij is het bij sha dus zo dat de entropie niet afneemt omdat alle mogelijk inputs van 512 bits lang bij sha512 verschillende outputs hebben.
Als dit niet zo is dan is de hashing functie niet een cryptografische hashing functie.

[ACM]

bwerg schreef op woensdag 20 juni 2012 @ 12:44:
Maar steeds als er onderzoek wordt gedaan naar nieuwe hashing-algoritmes is een van de eisen dat het zo snel mogelijk te berekenen is. Ik vraag me af waarom er nooit onderzoek wordt gedaan naar een wat zwaarder hashing-algoritme, aangezien dat dus ook zijn toepassingen heeft.

Uiteindelijk is de enige manier om het zwaarder te maken, ongeacht of je een 'snel' of 'langzaam' algoritme hebt, door het meer werk te laten doen. En meer werk met een relatief beperkte invoer zal doorgaans toch vooral enige vorm van looping zijn. En wellicht dat een of andere hele ingewikkelde variant een bepaald minimum aantal loops nodig heeft om te werken... maar uiteindelijk zal het qua werk niet per se verschillen van domweg een snellere functie te herhalen
Je moet verder nog oppassen dat je binnen zekere zinvolle grenzen moet blijven, 't is bijvoorbeeld niet erg praktisch als je honderden MB's nodig hebt om 1 key te berekenen en een prima methode om een hele erge DoS-situatie uit te lokken.

PiepPiep schreef op woensdag 20 juni 2012 @ 13:05:
Dat vraag ik me dus af, volgens mij is het bij sha dus zo dat de entropie niet afneemt omdat alle mogelijk inputs van 512 bits lang bij sha512 verschillende outputs hebben.
Als dit niet zo is dan is de hashing functie niet een cryptografische hashing functie.

Volgens mij is er geen garantie dat twee verschillende invoeren ook twee verschillende uitvoeren hebben, ongeacht de lengte van de invoer. Het is bij SHA wel heel ongebruikelijk dat keys korter dan 512 bytes niet een unieke uitkomst hebben, maar vziw is dat geen onderdeel van de definitie voor een cryptografische hashing functie.
Vziw is de enige definitie daarvan dat het heel moeilijk is om 'm om te keren?

[Cartman!]

ACM schreef op woensdag 20 juni 2012 @ 12:41:
[...]
Een wachtwoordhash is domweg een derived key. Alleen heeft PBKDF2 nog als toevoeging dat ie in principe ook een resultaat van willekeurige lengte kan aanleveren, ook als dat langer is dan de output van de hashfunctie. Je zou dus een key kunnen genereren van 65 bytes met zowel sha1 als sha512 als onderliggende methode. 't Is uiteraard een beetje 'zonde' om slechts 1 byte van de 64 die je van het 2e blok uit de interne pbkdf2-routine krijgt te gebruiken, maar voor de beveiliging is het niet eens zo heel relevant.

Duidelijk, bedankt! Ik gebruik overigens Whirlpool als algoritme met 10.000 iteraties en maak er een 128 byte output van.

edit: ik lees wel dat er aangeraden wordt om 256byte of zelfs 512byte output te genereren, doe ik dat bij m'n volgende project samen met dat ik er 20.000 iteraties maak van de 10.000 nu.

[ Voor 11% gewijzigd door Cartman! op 20-06-2012 14:38 ]

[Marcks]

Soultaker schreef op woensdag 20 juni 2012 @ 00:44:
[...]

Dat helpt wel. Als de verzameling van mogelijke wachtwoorden A is en de verzameling van uitkomsten van de hashfunctie daarop B is (dus B = { hash(x) for x in A }) dan kan het zijn dat B kleiner is dan A (kort: |B| <= |A|); dat is het probleem wat je noemt.

Maar de verzameling C = { hash(x) + x for x in A } heeft gegarandeerd dezelfde grootte als A (als de uitvoer van de hash-functie een vaste grootte heeft) omdat zelfs bij collisions het laatste deel nog uniek is.

Ah, je hebt gelijk. Verschillende wachtwoorden zullen op deze manier zeer waarschijnlijk niet naar dezelfde hashes convergeren. Ik doelde eigenlijk vooral het probleem dat van één wachtwoord de verzameling bij elke iteratie kleiner wordt. Ergo, begin met een willekeurige hash en het wachtwoord als verzameling A, welke dus 2⁵¹² groot is, en neem wederom B = { hash(x) + p for x in A }. Dan is B wel degelijk kleiner dan A, maar zelfs in het uiterste geval dat je na tal van iteraties de ruimte tot één cyclische hash hebt verkleind, d.w.z.: hash(x+p) = x, kun je er niet op aanvallen, daar je het oorspronkelijke wachtwoord nodig hebt om uit te rekenen welke hashes er afvallen en overblijven.

[...]

Interessant! Voorwaarde voor cryptografisch gebruik van zo'n hashfunctie is natuurlijk wel dat alle cycles voldoende lang zijn (idealiter is het één grote cycle) of dat korte cycles dusdanig zeldzaam zijn dat je ze praktisch gezien niet kunt vinden.

Dat is helaas niet het geval. De cycles zijn enkel voldoende lang wanneer de grootste gemene deler van de input x en het getal p-1 gelijk is aan 1. Andersom is de uitkomst van een bepaalde input enkel uniek wanneer de grootste gemene deler van het aantal iteraties n en het getal p-1 gelijk is aan één. Hoe groter deze gemene deler, des te meer collisions er optreden. Bovenal wordt het algoritme niet bepaald zwaarder door hem vaker uit te voeren, daar je h_n(x) kunt vereenvoudigen naar h(n x), welke, indien het getal (n x) te groot is, weer gelijk staat aan h((n x) mod (p-1)).

[Barryvdh]

Dus conclusie; niet zelf proberen het slimmer te doen dan frameworks/functies/standaarden die het al implementeren?

[Soultaker]

Marcks schreef op woensdag 20 juni 2012 @ 14:35:
Ik doelde eigenlijk vooral het probleem dat van één wachtwoord de verzameling bij elke iteratie kleiner wordt.

Dit volg ik niet. Voor één specifiek wachtwoord is er altijd maar één mogelijke uitvoer, want een hashfunctie is gewoon deterministisch. Voor één wachtwoord treedt het probleem van collisions dan ook niet op.

Ik weet niet of we het hier nu over eens zijn, maar mijn claim was dat het algoritme dat ik voorstelde (naar verwachting) evenveel collisions oplevert als éénmaal hashen, ongeacht hoeveel iteraties er uitgevoerd worden.

Barryvdh schreef op woensdag 20 juni 2012 @ 14:46:
Dus conclusie; niet zelf proberen het slimmer te doen dan frameworks/functies/standaarden die het al implementeren?

Dat is bij cryptografie altijd verstandig. Maar dan nog moet je goed begrijpen wat standaardfuncties precies wel en niet doen, anders kun je nog steeds grove fouten maken.

[bwerg]

ACM schreef op woensdag 20 juni 2012 @ 13:57:
Vziw is de enige definitie daarvan dat het heel moeilijk is om 'm om te keren?

Dat het moeilijk is om het om te keren (d.w.z. dat je één input kan vinden dat naar de gegeven output hashed, want er is niet één omkering natuurlijk), en dat het moeilijk is om willekeurige collisions-pairs te vinden.

Omkeerbare cryptografische functies zijn natuurlijk gewoon encryptie-functies en geen hashing-functies. Een hashing-functie mapt elke invoer bijna per definitie niet naar een unieke uitvoer, omdat de uitvoer doorgaans een bepaalde lengte heeft en de invoer niet. Alleen hashing-functies die ook een variabele lengte als uitvoer hebben kunnen in theorie een unieke uitvoer genereren (maar je wordt niet blij als je even een zo'n checksum-hash van je gedownloade Blu-ray wilt uitrekenen ).

[ACM]

Barryvdh schreef op woensdag 20 juni 2012 @ 14:46:
Dus conclusie; niet zelf proberen het slimmer te doen dan frameworks/functies/standaarden die het al implementeren?

Inderdaad, bij cryptografie is het fijn dat er een aantal standarisatieorganisaties zijn (zoals NIST) en andere partijen die er uitgebreid onderzoek naar doen. Helaas is het dan alsnog vaak lastig om het correct toe te passen.

Soultaker schreef op woensdag 20 juni 2012 @ 17:37:
Dit volg ik niet. Voor één specifiek wachtwoord is er altijd maar één mogelijke uitvoer, want een hashfunctie is gewoon deterministisch. Voor één wachtwoord treedt het probleem van collisions dan ook niet op.

Ik weet niet of we het hier nu over eens zijn, maar mijn claim was dat het algoritme dat ik voorstelde (naar verwachting) evenveel collisions oplevert als éénmaal hashen, ongeacht hoeveel iteraties er uitgevoerd worden.

Dat is toch wel degelijk het geval. Althans, als je deze quote mag geloven van de specificatie:

The iterates U_i are computed recursively to remove a degree of parallelism from an opponent; they are exclusive-ored together to reduce concerns about the recursion degenerating into a small set of values.

Ik heb hier meer over gelezen, maar kan het helaas niet zo snel meer terugvinden. 't Wordt trouwens op stack exchange wat verder besproken. Of de XOR wat nuttigs toevoegt is schijnbaar wat discutabel, maar domweg hash(hash(hash(...(x))) is vziw wel een bewezen zwak punt van simpelere algoritmes.

[Soultaker]

ACM schreef op woensdag 20 juni 2012 @ 19:59:
Dat is toch wel degelijk het geval. Althans, als je deze quote mag geloven van de specificatie:

Hebben we het nu nog over hetzelfde?

Mijn claim was dat:

1. Bij het berekenen van hash(password) een klein beetje entropie verloren gaat (omdat er mogelijke collisions zijn tussen twee passwords; de kans daarop is natuurlijk wel heel klein).
2. Bij het berekenen van een iterated hash als hash(hash(hash(...hash(password)...))) er méér entropie verloren gaat naarmate je meer hasht, omdat er bij elke stap collisions (kunnen) bijkomen.
3. Bij het berekenen van een iterated hash als hash(hash(hash(...hash(password)... + password) + password) + password) er ongeveer evenveel entropie verloren gaat als bij methode 1, maar niet meer, ongeacht hoe vaak je hasht.

Punt 1 en 2 lijken me onomstreden (toch?) terwijl Marcks en jij nog niet van punt 3 overtuigd zijn (of begrijp ik dat verkeerd?)

Ik heb hier meer over gelezen, maar kan het helaas niet zo snel meer terugvinden. 't Wordt trouwens op stack exchange wat verder besproken. Of de XOR wat nuttigs toevoegt is schijnbaar wat discutabel, maar domweg hash(hash(hash(...(x))) is vziw wel een bewezen zwak punt van simpelere algoritmes.

Zoals daar ook gezegd wordt is dat ten dele een voorschot op mogelijke zwakheden in het gebruikte hash-algoritme. De rest van de analyse (met betrekking tot het krimpen van de verzameling mogelijke tussenwaarden) klopt i.m.o. niet omdat de gebruikte PRF specifiek is voor het gebruikte wachtwoord. (Dat is eigenlijk dezelfde fout die Marcks ook maakte.)

[deadinspace]

jbdeiman schreef op woensdag 20 juni 2012 @ 11:50:
Wat mij vooral opvalt is dat er vaak een vaste positie voor een Salt of Pepper wordt gebruikt. Waarom is dat?

Omdat het niet uitmaakt (en het dus beter is om de eenvoudigste optie te kiezen).

De aangevallen service (Alice) moet het volgende doen: een opgegeven wachtwoord verifiëren tegen een opgeslagen hash (evt met salt). Een aanvaller die één of meerdere hashes in handen krijgt kan die hashes niet inverteren (uitgaande van een degelijke hashfunctie) zonder te bruteforcen (al dan niet met dictionary).

Het enige dat een aanvaller (Eve) dus kan doen is een mogelijk wachtwoord genereren en verifiëren tegen een bemachtigde hash (incl evt salt). Dat is dus exact dezelfde operatie als Alice doet (!) alleen waarschijnlijk veel vaker.

Postitie kan je ook "bepalen" op basis van een aantal gegevens, waardoor positie van de salt en/ of pepper ook kan wisselen.

De stappen die Alice doet om van een wachtwoord + hash te bepalen of het wachtwoord klopt moeten reproduceerbaar zijn, anders kan Alice het volgende keer zelf niet controleren. Stappen die Alice uitvoert kan Eve ook uitvoeren. Als alice (bv aan de hand van gebruikers id, ik noem maar wat) uit kan rekenen waar de salt geinsert moet worden, dan kan Eve dat ook.

De valkuil waar jij in lijkt te trappen is "ingewikkelder is veiliger, want dan weet de aanvaller niet hoe ik het doe", maar dat is een gevaarlijke aanname. Als de aanvaller je code in kan zien (en dat is geen raar idee als hij heeft ingebroken en je hashes heeft bemachtigd) valt dat hele voordeel in het water.

Je moet er altijd van uitgaan dat een aanvaller alles van je systeem weet, behalve de sleutels (waar wachtwoorden een vorm van zijn). Dit is een van de grondregels van de cryptografie.

Bijv:

Wachtwoord A!5p128P
Salt: A*S1s

Als je dan A!5pA*S1s128P gaat hashen dan wens ik iedereen veel succes met het terug redeneren van het wachtwoord.

Het is voor de aanvaller niet moeilijker om A!5pA*S1s128P te bruteforcen dan A*S1sA!5p128P.

Hashen is leuk, maar het grootste probleem is de eenvoud van de wachtwoorden die worden gebruikt.

Dat is zeker waar, maar daar verander je op deze manier niets aan.

[...] maar als je in een wachtwoord verplicht stelt (dat kan je als minimale beveiligingseis stellen) er speciale tekens in moeten komen en je doet hetzelfde met de hash (ook speciale tekens)

Het al of niet aanwezig zijn van speciale tekens is irrelevant; het enige dat er toe doet (voor zowel salts als wachtwoorden) is de hoeveelheid entropie ('willekeurigheid') in een wachtwoord.

[.oisyn]

Waarom is deze topic compleet aan mij voorbijgegaan?

tvp

deadinspace schreef op donderdag 21 juni 2012 @ 10:00:
Het al of niet aanwezig zijn van speciale tekens is irrelevant; het enige dat er toe doet (voor zowel salts als wachtwoorden) is de hoeveelheid entropie ('willekeurigheid') in een wachtwoord.

Klopt. Het aantal verschillende wachtwoorden dat mogelijk is is cⁿ, met c het aantal verschillende karakters (62 voor strict alphanumerieke wachtwoorden) en n het aantal karakters in het wachtwoord. Je wil dat getal zo groot mogelijk hebben. Je kan er dus voor kiezen om c te vergroten door speciale tekens te gebruiken, of simpelweg n te vergroten door je wachtwoord langer te maken.

Het probleem met speciale tekens is dat het vooral moeilijker wordt voor de mens om te onthouden, waardoor men óf n klein houdt óf de wachtwoorden ergens op gaat schrijven. En dat terwijl een computer er juist helemaal geen moeite mee heeft om ze af te lopen. Handiger is dus een makkelijk te onthouden wachtwoord met grote n (zoals een combinatie van woorden of een zin) te gebruiken. Jammer genoeg vereisen veel systemen vooral een grote c (zoals: minstens 1 hoofdletter, 1 kleine letter, 1 cijfer en 1 leesteken) . Gelukkig hebben ze dat op t.net aangepast en wordt tegenwoordig gewoon de entropie van een wachtwoord berekend om te kijken of hij sterk genoeg is

[ Voor 98% gewijzigd door .oisyn op 21-06-2012 11:16 ]

[Cartman!]

Dit dus: http://xkcd.com/936/

[Grijze Vos]

deadinspace schreef op donderdag 21 juni 2012 @ 10:00:
[...]

Omdat het niet uitmaakt (en het dus beter is om de eenvoudigste optie te kiezen).

Bij een partial breach (alleen je DB server bijv., en niet je webserver) kan dit klein beetje security through obscurity toch net de "redding" zijn.

[CyBeR]

.oisyn schreef op donderdag 21 juni 2012 @ 11:02:

Klopt. Het aantal verschillende wachtwoorden dat mogelijk is is cⁿ, met c het aantal verschillende karakters (62 voor strict alphanumerieke wachtwoorden) en n het aantal karakters in het wachtwoord.
[..]
Jammer genoeg vereisen veel systemen vooral een grote c (zoals: minstens 1 hoofdletter, 1 kleine letter, 1 cijfer en 1 leesteken) .

Wat vreemd is eigenlijk, want iedereen met een middelbareschooldiploma moet toch weten dat bij cⁿ, het verhogen van n veel meer effect heeft dan het verhogen van c.

[Cloud]

CyBeR schreef op donderdag 21 juni 2012 @ 13:26:
[...]

Wat vreemd is eigenlijk, want iedereen met een middelbareschooldiploma moet toch weten dat bij cⁿ, het verhogen van n veel meer effect heeft dan het verhogen van c.

Ik denk dat het probleem is dat niet veel mensen beseffen dat het aantal mogelijkheden door cⁿ bepaald wordt. Ze denken bij het 'breken' van wachtwoorden aan zichzelf, aan hoe mensen het zouden doen. En voor mensen is het gevoelsmatig lastiger om wachtwoorden te 'raden' met vreemde tekens, dan alfanumerieke wachtwoorden.

Niet iedereen denkt zo ver over zaken na als wij IT'ers hé

[.oisyn]

Ik vind "als wij IT'ers" overigens alsnog een behoorlijke overschatting van de security-skills van de gemiddelde IT'er. Zelfs t.net had tot voor kort gewoon ongesalte MD5 hashes van de wachtwoorden in de database staan. Én de eis dat er een hoofletter, kleine letter en cijfer in moesten nadat ze dat systeem hadden aangepast. Het is waarschijnlijk ook vaak meer een gevalletje van "iedereen doet het zo, dus zal het wel goed zijn", zonder er zelf even over na te denken

[ Voor 37% gewijzigd door .oisyn op 21-06-2012 15:04 ]

[deadinspace]

Grijze Vos schreef op donderdag 21 juni 2012 @ 13:18:
Bij een partial breach (alleen je DB server bijv., en niet je webserver) kan dit klein beetje security through obscurity toch net de "redding" zijn.

Dat is waar, maar je kunt daar absoluut niet op vertrouwen. En dat doen mensen in de praktijk vaak wel. Dat is verreweg het grootste probleem van security through obscurity; het geeft een vals gevoel van veiligheid. In plaats van "het kleine beetje dat je toevallig kan redden" wordt het snel gezien als een degelijke maatregel, wat het nooit is.

Als je wil beschermen tegen een partial breach zou ik voorstellen een statische site-specific salt toe te voegen die niet in de DB staat. Dus iets a la hash( $site_salt + $random_salt + $password ). Dit helpt op eenzelfde manier, maar dan met een meetbare veiligheid voor specifieke scenario's. En het is simpeler, dus het risico op het maken van fouten is kleiner. En je kunt voor elke site een eigen statische salt gebruiken (en dus risico's verder segmentiseren).

CyBeR schreef op donderdag 21 juni 2012 @ 13:26:
Wat vreemd is eigenlijk, want iedereen met een middelbareschooldiploma moet toch weten dat bij cⁿ, het verhogen van n veel meer effect heeft dan het verhogen van c.

Dat hangt van de specifieke c en n af. Bij 2³⁰ helpt het verhogen van c wel degelijk meer

Maargoed, wachtwoorden hebben doorgaans een relatief grote c en kleine n, dus binnen de context heb je natuurlijk gelijk.

[Cloud]

.oisyn schreef op donderdag 21 juni 2012 @ 14:56:
Ik vind "als wij IT'ers" overigens alsnog een behoorlijke overschatting van de security-skills van de gemiddelde IT'er.
[...]

Dat bevestigt mijn punt alleen maar; als 'wij IT'ers' het al lang niet allemaal goed doen, ga dan maar na hoe een atechnisch persoon over dit soort dingen nadenkt. Amper tot helemaal niet dus

Verder heb je helemaal gelijk, tot voor kort deed iedereen elkaar gewoon na zonder erover na te denken. Pas recentelijk zijn mensen er meer over na gaan denken, omdat korte wachtwoorden en/of verouderde algoritmen nu door huis tuin en keuken machines al te bruteforcen zijn. En in het licht van de recente DB hacks natuurlijk waarbij miljoenen hashes zonder salt gepakt worden.

[Beatboxx]

Ik zeg bcrypt. Eerst even de class bcrypt in je code zetten. (Zie hie) en dan:

PHP:

$bcrypt = new Bcrypt(15);
$pass = 'abcd';
$hash = $bcrypt->hash('password')

Verder hanteer ik zelf de policy dat als een user 5x achter elkaar fout password doet, ie 15min geblockt wordt. Daarna nog 2x fout? Uur geblocked. Nog 2 fouten = permanente ban.

[Mr_gadget]

Dat is nog redelijk toegeeflijk in vergelijking met andere systemen.

Vind het trouwens wel erg irritant dat je bij sommige banken je wachtwoord zeer regelmatig moet vervangen. Heb je een sterk wachtwoord wat je kan onthouden dan kies je vaak alsnog weer een makkelijk wachtwoord omdat het lastig is weer een nieuw goed wachtwoord te bedenken

[.oisyn]

Ja banken hebben het op een of ander manier het minst begrepen van allemaal. Ironisch genoeg is mijn bank-wachtwoord tevens degene waar ik het meeste waarde aan hecht

[ Voor 36% gewijzigd door .oisyn op 21-06-2012 15:20 ]

[chrisO]

Beatboxx schreef op donderdag 21 juni 2012 @ 15:15:
Ik zeg bcrypt. Eerst even de class bcrypt in je code zetten. (Zie hie) en dan:

PHP:

$bcrypt = new Bcrypt(15);
$pass = 'abcd';
$hash = $bcrypt->hash('password')

Verder hanteer ik zelf de policy dat als een user 5x achter elkaar fout password doet, ie 15min geblockt wordt. Daarna nog 2x fout? Uur geblocked. Nog 2 fouten = permanente ban.

Dus even 9 maal een foutief wachtwoord invullen voor wat random accounts om gebruikertjes te pesten

[.oisyn]

Ik zou idd eerder het ip even blokken dan het account zelf. En een mailtje sturen naar de eigenaar van het account (met eventueel een unblock linkje erin)

[Anoniem: 159396]

Beatboxx schreef op donderdag 21 juni 2012 @ 15:15:
Verder hanteer ik zelf de policy dat als een user 5x achter elkaar fout password doet, ie 15min geblockt wordt. Daarna nog 2x fout? Uur geblocked. Nog 2 fouten = permanente ban.

Wij blokkeren op IP-adres met per fout wachtwoord een wachttijd maal 2

Dus: 1 keer verkeerd invullen, 2 seconden wachten
2 keer - 4 seconden
3 keer - 8 seconden
4 keer - 16 seconden
...