lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 28 Oct 2013 17:34:19 -0700 From: "Jeremy Spilman" <jeremy@...link.co> To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net> Subject: Post-hoc Strengthening You don't *need* the original password in order to strengthen a hash, but it tends to get overcomplicated if you try to strengthen a hash value without it. But it doesn't need to be this way... Take PBKDF2 for example, and lets also assume the 'derived key' length is equal to the HMAC block size to further simplify things: result = HMAC(Password, Salt || 1) for 2..n result ^= HMAC(Password, result) It's clear we can increase iteration count without starting from the beginning, but we would need to know the password, which defeats the point. Versus a slight tweak to PBKDF2 which would have made it trivial to allow post-hoc strengthening without the password: result = HMAC(Password, Salt || 1) for 2..n result ^= HMAC(Salt, result) Maybe there's a reason to *require* the password to keep creating work past the first iteration, but at first glance I don't see it. In case it's not clear, the use case here is writing a background task which can strengthen the password hashes for all users in the database, without having to touch your production code for validating logins. Simple post-hoc strengthening without needing the password sounds like a great property for a password-hashing algorithm to have. It's obviously a bit harder to achieve this property on memory-hard hashing functions since, to state the requirement differently, it requires recovering full state of the hashing function from just whatever is stored in the user table. Thanks, Jeremy
Powered by blists - more mailing lists