Hoe kun je wachtwoorden checken, als je de salt niet weet?

[Hatsieflatsie]

Ik ontdekte onlangs dat PHP een vrij recente functie heeft, password_hash().

De salt wordt automatisch genereerd. Dit begrijp ik echter niet. Stel, we hebben het volgend wachtwoord: kees. Deze wordt met md5 gehasht naar 1234.

Voegen we onze salt toe: piet. Dus de wachtwoord is pietkees. Deze wordt door md5 gehasht tot 67891234

Wanneer kees z'n wachtwoord invoert, wordt dit aan de backend samengevoegd met de salt 'piet'. En gehasht tot een combinatie, dat overeenkomt met het gehashte wachtwoord.

Maar als je random salt genereert, dan krijg je toch nooit het juiste wachtwoord omdat dit niet overeenkomt met de gehashte salt? Of mis ik iets fundamenteels? .

[ Voor 3% gewijzigd door Hatsieflatsie op 21-06-2016 20:26 ]

[orf]

Heb je dit stukje gelezen?

The used algorithm, cost and salt are returned as part of the hash. Therefore, all information that's needed to verify the hash is included in it. This allows the password_verify() function to verify the hash without needing separate storage for the salt or algorithm information.

[naam]

nvm, ik lees te snel

[ Voor 77% gewijzigd door naam op 21-06-2016 20:29 ]

[Cartman!]

Hatsieflatsie schreef op dinsdag 21 juni 2016 @ 20:25:
Of mis ik iets fundamenteels? .

Ja dus Zie het als "<algo>|<salt>|<password>" en als ie die informatie niet heeft zal hij het algoritme gebruiken dat er is ingesteld bij het aanroepen van de functie en de salt maken.

[Hatsieflatsie]

orf schreef op dinsdag 21 juni 2016 @ 20:29:
Heb je dit stukje gelezen?


[...]

Cartman! schreef op dinsdag 21 juni 2016 @ 20:59:
[...]

Ja dus Zie het als "<algo>|<salt>|<password>" en als ie die informatie niet heeft zal hij het algoritme gebruiken dat er is ingesteld bij het aanroepen van de functie en de salt maken.

In de comments lees ik echter ook dat de salt genereerd wordt met behulp van output uit de
/dev/urandom

Waar wordt de genereerde salt dan opgeslagen? Die heb je immers als referentiepunt nodig, om de combinatie van wachtwoord te unhashen.

[Xander]

Hatsieflatsie schreef op dinsdag 21 juni 2016 @ 20:25:
De salt wordt automatisch genereerd. Dit begrijp ik echter niet. Stel, we hebben het volgend wachtwoord: kees. Deze wordt met md5 gehasht naar 1234.

Voegen we onze salt toe: piet. Dus de wachtwoord is pietkees. Deze wordt door md5 gehasht tot 67891234

Nee, de hash wordt piet67891234.

[Cartman!]

Hatsieflatsie schreef op dinsdag 21 juni 2016 @ 21:04:
[...]


[...]
In de comments lees ik echter ook dat de salt genereerd wordt met behulp van output uit de
/dev/urandom

Dat hangt af van het OS waar je op zit.

Waar wordt de genereerde salt dan opgeslagen? Die heb je immers als referentiepunt nodig, om de combinatie van wachtwoord te unhashen.

Dat leg ik toch net uit? En unhashen bestaat niet natuurlijk

Van wikipedia over bcrypt is exact wat ik bedoel:

For example, the shadow password record $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy specifies a cost parameter of 10, indicating 210 key expansion rounds. The salt is N9qo8uLOickgx2ZMRZoMye and the resulting hash is IjZAgcfl7p92ldGxad68LJZdL17lhWy. Per standard practice, the user's password itself is not stored.

[ Voor 28% gewijzigd door Cartman! op 21-06-2016 21:13 ]

[Haan]

Xander schreef op dinsdag 21 juni 2016 @ 21:07:
[...]


Nee, de hash wordt piet67891234.

Eh, je hasht de input + salt, de salt plak je niet achter een hash

[Hydra]

Haan schreef op dinsdag 21 juni 2016 @ 21:11:
Eh, je hasht de input + salt, de salt plak je niet achter een hash

Je slaat de salt gewoon op. Dit kan samen met de hash in 1 veld of in een apart veld. Dat maakt niet uit.

In 't geval van bijvoorbeeld pbkdf2 sla je <iterations>:<salt>:<hash> op.

De bedoeling van een salt is niet om het password bruteforcen moeilijker te maken. De bedoeling is dat je als je erachter komt dat mijn password 'pietje' is je niet meteen ook van alle andere die 'pietje' als password hebben dat weet.

Het password bruteforcen zelf maak je moeilijker door niet iets waardeloos als MD5 of SHA te gebuiken maar bcrypt, scrypt of pbkdf2. De laatste 2 hebben een voorkeur want zijn moeilijk met een GPU te doen.

[ Voor 38% gewijzigd door Hydra op 21-06-2016 21:33 ]

[Xander]

Haan schreef op dinsdag 21 juni 2016 @ 21:11:
[...]

Eh, je hasht de input + salt, de salt plak je niet achter een hash

Je hasht de input+salt (daarom komt er naar het voorbeeld van de TS ook 67891234 uit en niet 1234), maar plakt in dit geval de salt ook voor het resultaat.

Zie ook de quote van Cartman!

[Haan]

Ja ok, je slaat de salt en hash natuurlijk op, dat is waarschijnlijk wat je bedoelde, maar de hash zelf zie je de salt niet in terug.

[henk1994]

Als je de documentatie (en dan met name de voorbeelden) leest zal je het waarschijnlijk beter begrijpen. http://php.net/manual/en/function.password-hash.php

Wat er gebeurt is het volgende.

PHP:

password_hash("rasmuslerdorf", PASSWORD_DEFAULT)

Dit geeft ongeveer deze output:
$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a

In deze hash zit alle informatie, de salt, en het wachtwoord.

Van de website van PHP:

quote: http://php.net/manual/en/function.password-verify.php

Note that password_hash() returns the algorithm, cost and salt as part of the returned hash. Therefore, all information that's needed to verify the hash is included in it. This allows the verify function to verify the hash without needing separate storage for the salt or algorithm information.

[Verwijderd]

orf schreef op dinsdag 21 juni 2016 @ 20:29:
The used algorithm, cost and salt are returned as part of the hash. Therefore, all information that's needed to verify the hash is included in it. This allows the password_verify() function to verify the hash without needing separate storage for the salt or algorithm information.

Moet ik dit begrijpen als volgt: de password_verify() functie weet welke salt gebruikt werd tijdens het hashen door het opgeslagen resultaat?

[Cartman!]

Verwijderd schreef op woensdag 22 juni 2016 @ 20:22:
[...]


Moet ik dit begrijpen als volgt: de password_verify() functie weet welke salt gebruikt werd tijdens het hashen door het opgeslagen resultaat?

Is dat hierboven niet nu al 4 keer bevestigd inmiddels?

[orf]

Verwijderd schreef op woensdag 22 juni 2016 @ 20:22:
[...]


Moet ik dit begrijpen als volgt: de password_verify() functie weet welke salt gebruikt werd tijdens het hashen door het opgeslagen resultaat?

password_hash() geeft een string terug waar de gebruikte hashing methode in zit, de iteraties, de salt en de hash van het password. password_verify() gebruikt die string om te checken of het wachtwoord gelijk is. Je slaat de output van password_hash() op in de database en controleert dat bij elke login met password_verify().

[henk1994]

Verwijderd schreef op woensdag 22 juni 2016 @ 20:22:
[...]


Moet ik dit begrijpen als volgt: de password_verify() functie weet welke salt gebruikt werd tijdens het hashen door het opgeslagen resultaat?

Ja, als je password_hash() gebruikt wel. Er zit een algoritme achter waarin dus alle gegevens opgeslagen worden. Salten is niet direct om het veiliger te maken, enkel om jezelf tegen rainbow tables te beschermen. Het is dus niet erg dat de salt erin staat.

[Verwijderd]

is het zo eenvoudig dat we de salt rechtstreeks kunnen uitlezen als een substring uit de hash? Of zit daar nog een algoritme in dat eerst de salt uit de hash haalt en dan pas verder kan?

[HollowGamer]

Wat wil je precies bereiken? Ik snap de vraag niet.

[MarcoC]

Verwijderd schreef op donderdag 23 juni 2016 @ 09:37:
is het zo eenvoudig dat we de salt rechtstreeks kunnen uitlezen als een substring uit de hash? Of zit daar nog een algoritme in dat eerst de salt uit de hash haalt en dan pas verder kan?

Dat is zo eenvoudig ja. Het doel van de salt is om elke hash uniek te maken, ongeacht of het wachtwoord uniek is. Op deze manier kan je door één password te kraken er niet direct achterkomen wie nog meer hetzelfde wachtwoord heeft.

[Verwijderd]

Ik begrijp het principe van salts wel hoor. Welk deel van de hash is de salt dan?

[Xander]

Haan schreef op woensdag 22 juni 2016 @ 11:31:
Ja ok, je slaat de salt en hash natuurlijk op, dat is waarschijnlijk wat je bedoelde, maar de hash zelf zie je de salt niet in terug.

Juist, volgens mij bedoelen we stiekem hetzelfde. Die functie geeft een string terug die (o.a.) de salt en de hash bevat. Die output noem ik "hash", maar dat is natuurlijk niet de correcte benaming. Maar welk naampje ik daar dan wel aan zou moeten geven...?

[Barryvdh]

Verwijderd schreef op donderdag 23 juni 2016 @ 09:54:
Ik begrijp het principe van salts wel hoor. Welk deel van de hash is de salt dan?

Maakt niet uit.

The used algorithm, cost and salt are returned as part of the hash. Therefore, all information that's needed to verify the hash is included in it. This allows the password_verify() function to verify the hash without needing separate storage for the salt or algorithm information.

Gewoon de hash in zijn geheel opslaan in de database naast je username/email. Bij verifiëren, heel die hash in password_verify stoppen.

[MarcoC]

Barryvdh schreef op donderdag 23 juni 2016 @ 10:09:
[...]

Maakt niet uit.

Je geeft geen antwoord op zijn vraag. Hij wil weten welk gedeelte van de hash nou precies de salt is. Antwoord: dat is afhankelijk van het algoritme.

Hier staat het duidelijk uitgelegd in het geval je bcrypt gebruikt: http://stackoverflow.com/...crypt-have-built-in-salts

[Verwijderd]

ok bedankt, de stackoverflow post maakt veel duidelijk

[Barryvdh]

MarcoC schreef op donderdag 23 juni 2016 @ 10:14:
[...]

Je geeft geen antwoord op zijn vraag. Hij wil weten welk gedeelte van de hash nou precies de salt is. Antwoord: dat is afhankelijk van het algoritme.

Hier staat het duidelijk uitgelegd in het geval je bcrypt gebruikt: http://stackoverflow.com/...crypt-have-built-in-salts

Klopt, omdat hij waarschijnlijk iets aan het doen is wat niet klopt/nodig is. Maar dat is lastig inschatten omdat hij niet aangeeft waarom hij alleen de salt wil hebben.

[ajakkes]

Barryvdh schreef op donderdag 23 juni 2016 @ 10:52:
[...]

Klopt, omdat hij waarschijnlijk iets aan het doen is wat niet klopt/nodig is. Maar dat is lastig inschatten omdat hij niet aangeeft waarom hij alleen de salt wil hebben.

Omdat hij wil begrijpen wat er gebeurt.

De zon draait om de aarde. Waarom draait de zon om de aarde? Dat is niet belangrijk! Gewoon om 7:00 opstaan en aan het werk.

[Barryvdh]

ajakkes schreef op donderdag 23 juni 2016 @ 20:49:
[...]


Omdat hij wil begrijpen wat er gebeurt.

De zon draait om de aarde. Waarom draait de zon om de aarde? Dat is niet belangrijk! Gewoon om 7:00 opstaan en aan het werk.

Soms is de 'waarom' belangrijker dan de 'hoe'
In dit geval is het gewoon niet erg relevant hoe je de salt uit de hash krijgt. In 99% van de gevallen heb je dat namelijk niet nodig. En als je denkt die nodig te hebben, dan is er dus een grote kans dat je het aan het misbruiken bent.

Maargoed, als het puur interesse is (om nog maar beetje on-topic te blijven), dan kan je ook de PHP versie van password_hash ed. bekijken, om te zien wat er op de achtergrond gebeurt (waarschijnlijk makkelijker leesbaar als de C versie).
https://github.com/ircmax...b/master/lib/password.php

[ajakkes]

Barryvdh schreef op donderdag 23 juni 2016 @ 22:49:
[...]

Soms is de 'waarom' belangrijker dan de 'hoe'
In dit geval is het gewoon niet erg relevant hoe je de salt uit de hash krijgt. In 99% van de gevallen heb je dat namelijk niet nodig. En als je denkt die nodig te hebben, dan is er dus een grote kans dat je het aan het misbruiken bent.

Maargoed, als het puur interesse is (om nog maar beetje on-topic te blijven), dan kan je ook de PHP versie van password_hash ed. bekijken, om te zien wat er op de achtergrond gebeurt (waarschijnlijk makkelijker leesbaar als de C versie).
https://github.com/ircmax...b/master/lib/password.php

Om te beginnen is het belangrijk om te weten wat de salt is om zeker te weten dat er een 'per password salt' is.

Als je geen salt ziet en niet snapt hoe het dan kan werken, wat de vraag van TS was, dan kan je geen vertrouwen hebben dat het betrouwbaar werkt. En roept het de vraag op of je het wel juist hebt geïmplementeerd.

En daarmee heb ik meer vertrouwen in de vraagsteller dan in de persoon die zegt: het antwoord op de vraag is niet belangrijk zolang je doet wat er staat en ik vertel het liever niet want ben bang dat je het dan verkeerd implementeert.