Mijn pbkdf2 sha512 hash is anders dan die van applicatie

[dhs]

Er is bij ons op kantoor een .NET webapplicatie in gebruik die een 'change password' functionaliteit ontbeert. Na even snuffelen in de database kom ik er achter dat de passwords enigszins gestructureerd opgeslagen zijn, fijn dacht ik.. dan bouw ik zelf in PHP een change-password pagina.

Het password-veld in de database van de applicatie heeft de volgende content bij een gebruiker met als wachtwoord alleen een 'a'.

code:

$pbkdf2_sha512$iter=7d0$v1t2oGEfc7cJf0vy$8ANP+A+6nKCOtx/f0VoI4HuXUFxTdmw13vpy5tZPRt7z10BT+hwBNWvsRpfcnQkjHIj8YGRhmz0UXdzipnEX/A==

Duidelijke parameters dacht ik: pbkdf2 crypto functie met sha512 gehashde key. De volgende parameter is het aantal iterations in hexadecimaal, 7d0 = 2000. De volgende parameter moet de salt zijn, lijkt base64. Net als de laatste parameter, de hash zelf in base64.

In PHP vervolgens de volgende code gebruikt om de hash te berekenen:

PHP:

$originalhash = "8ANP+A+6nKCOtx/f0VoI4HuXUFxTdmw13vpy5tZPRt7z10BT+hwBNWvsRpfcnQkjHIj8YGRhmz0UXdzipnEX/A==";

$password = "a";
$iterations = 2000;
$salt = base64_decode("v1t2oGEfc7cJf0vy");

$calculatedhash = hash_pbkdf2("sha512", $password, $salt, $iterations, 0, true );

echo "<table>";
echo "<tr><td>Original hash</td><td>".$originalhash."</td></tr>";
echo "<tr><td>Calculated hash</td><td>".base64_encode($calculatedhash)."</td></tr>";
echo "</table>";

Met als resultaat:

code:

Original hash   8ANP+A+6nKCOtx/f0VoI4HuXUFxTdmw13vpy5tZPRt7z10BT+hwBNWvsRpfcnQkjHIj8YGRhmz0UXdzipnEX/A==
Calculated hash lVUYgBmbuqEJoXYS57wGykiIuS8WaTmnYeTIDlKodO2K1tzZv5KhcNdh0dn+M8qHDtIn3OzAdnP0VPDNyFIspQ==

Nou is het probleem dat ik met geen mogelijkheid dezelfde hash krijg als die in de database staat. Ik heb ook al geprobeerd de salt als string in de functie te doen ipv binary maar daarmee kom ik niet op de juiste hash uit. Wat zie ik over het hoofd?

[GrooV]

Wat voor een .NET applicatie is het? Als het iets intern ontwikkeld is dan is de kans groot dat het niet obfuscated is en kan je de het decompilen om de source code te zien met bijvoorbeeld

https://www.jetbrains.com/decompiler/

Zodra je de source hebt kan je zien hoe de hash in de .NET applicatie berekend wordt

edit: Heb even snel getest maar bij mij test .NET applicatie komt er de zelfde hash uit als in jouw PHP applicatie, er gebeurt dus nog wat meer

[Voor 40% gewijzigd door GrooV op 21-12-2022 09:55]

[dhs]

Dank voor de tip, het is niet intern ontwikkeld maar commercieel. Heb helaas geen beschikking over de source. Mogelijk prefixen ze de salt ergens mee..

[GrooV]

dhs schreef op woensdag 21 december 2022 @ 09:56:
Dank voor de tip, het is niet intern ontwikkeld maar commercieel. Heb helaas geen beschikking over de source. Mogelijk prefixen ze de salt ergens mee..

Ja dat snap ik, daarom moet je het proberen te decompilen

[Merethil]

Als je

code:

v1t2oGEfc7cJf0vy

decoded dan krijg je een aantal non-printable chars. Volgens mij is die óf niet base64 encoded, óf pak je niet genoeg karakters.

Passlib geeft aan dat zij adapted base64 gebruiken waarbij whitespace en padding verwijderen. Ik weet niet of de .net-variant dat ook doet?

[Voor 29% gewijzigd door Merethil op 21-12-2022 11:26]

[Voutloos]

Je bent er vast van bewust, maar ik wil het toch maar even zeggen: Meerdere applicaties toegang geven tot wachtwoorden zou inmiddels een code smell moeten zijn. Die verantwoordelijkheid en het aanvalsoppervlakte moet je niet lange termijn willen hebben met security en GDPR etc anno nu.

[GrooV]

Merethil schreef op woensdag 21 december 2022 @ 11:18:
Als je

code:

v1t2oGEfc7cJf0vy

decoded dan krijg je een aantal non-printable chars. Volgens mij is die óf niet base64 encoded, óf pak je niet genoeg karakters.

Passlib geeft aan dat zij adapted base64 gebruiken waarbij whitespace en padding verwijderen. Ik weet niet of de .net-variant dat ook doet?

Is waarschijnlijk een byte[] naar base64

[DJMaze]

dhs schreef op woensdag 21 december 2022 @ 09:14:
Het password-veld in de database van de applicatie heeft de volgende content bij een gebruiker met als wachtwoord alleen een 'a'.

Wat voor idiote applicatie accepteert zo kort wachtwoord?

Als ze een minimum hebben van 8 tekens of zo, dan lijkt er een fout te zitten in hun controles en zal het wel iets zijn als "$passphrase = $salt + $pass + $salt" en daarna een controle op lengte.
De $salt die ik aanhaal zit vast in de software ingebakken (de licentiecode?) zodat iemand niet zomaar met een kopie van de database aan de haal kan.

[Voutloos]

Voor debuggen is een eenvoudige inputwaarde natuurlijk prima. Als je het hashen van 'a' niet correct krijgt heeft de rest ook geen zin.

[DataGhost]

DJMaze schreef op donderdag 22 december 2022 @ 13:21:
[...]

De $salt die ik aanhaal zit vast in de software ingebakken (de licentiecode?) zodat iemand niet zomaar met een kopie van de database aan de haal kan.

In dat geval heet het een pepper

[J2pc]

DataGhost schreef op donderdag 22 december 2022 @ 15:33:
[...]

In dat geval heet het een pepper

Ik denk dat ze idd iets pre/postfixen aan het ww voordat ze gaan hashen.
Want als ik zo even met python en hashcat piel lijkt je aanpak wel te werken, en conistent met bijvoorbeeld de example hashes van hashcat (https://hashcat.net/wiki/doku.php?id=example_hashes type 12100)

Gelukkig (maar helaas voor jou) is dit een vrij goede manier om wachtwoorden op te slaan (traag om te berekenen) dus die 'pepper' vis je er niet zomaar uit, zeker niet als ie wat langer is.