Req #75388 [Com]: Argon2: Add secret/key

From: Date: Sat, 30 Mar 2019 20:17:13 +0000
Subject: Req #75388 [Com]: Argon2: Add secret/key
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-220259@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=75388&edit=1 ID: 75388 Comment by: phpdoc at mail dot my1 dot info Reported by: phpdoc at mail dot my1 dot info Summary: Argon2: Add secret/key Status: Assigned Type: Feature/Change Request Package: *Encryption and hash functions Operating System: Win8.1 x64 PHP Version: Next Minor Version Assigned To: jedisct1 Block user comment: N Private report: N New Comment: @jedisct1 okay let me say a few things: 1) I am NOT mainly talking about libsodium, but about password_hash, which iirc didnt rely on Sodium for hashing. 2) while the reference EXECUTABLE doesnt have the secret/pepper parameter, I want to quote the site of the ref implementation: https://github.com/P-H-C/phc-winner-argon2 "libargon2 provides an API to both low-level and high-level functions for using Argon2 [...] The secret parameter, which is used for keyed hashing. This allows a secret key to be input at hashing time (from some external location) and be folded into the value of the hash. This means that even if your salts and hashes are compromized, an attacker cannot brute-force to find the password without the key." and as far as I am aware password_hash does use libargon2, so it should be possible to add the parameters. 3) while encryption MIGHT be adecent workaround when a proper pepper system is not available, one might wanna note that if someone knew the key they could go and decrypt the hashes and if for some reason the randomness for the salts was screwed (let me remind you that things like debian weak keys happen) one could rainbow table the fun once and have the hashes of anyone who got the key, but with a properly built-in pepper you can't just restore the "normal" salted hash from the end result. also when re-keying an attacker who got access to the key multiple times they could see whether a target changed their password, which would obviously not happen when playing pepper games. to top it off when the pepper leaks (no matter whether in-hash or encryption-style) it might (depending on the application) to force the users to change their passwords anyway and if you would just re-encrypt the same old passwords you could also just ask the users to login which would allow to re-hash the passwords without having to reset them. I personally think both ways have their merits and there isnt too much against giving this to the users. Previous Comments: ------------------------------------------------------------------------ [2019-03-30 19:51:45] jedisct1@php.net All Argon2 parameters get mixed the same way. You can add 3 extra passwords, 2 contexts and 5 more peppers with no changes to the design. The pepper was documented to improve interoperability between implementations willing to use this, but there is nothing special about the pepper/secret. The reference argon2 tool doesn't support peppers. The value of a pepper is debatable, especially since encrypting hashes is better both from an operational and a security perspective. If the pepper is leaked, you need to reset the passwords of your entire user base. The importance of encryption (including salt encryption) was pointed out and discussed by Yescrypt's author after the competition was over. libsodium does not and will not support peppers. PHP wrappers cannot expose a parameter that doesn't exist. ------------------------------------------------------------------------ [2019-03-29 16:39:17] phpdoc at mail dot my1 dot info @jedisct1 but isnt that basically also just the makers of that package making their own crypto? I mean encrypting the hash shouldnt be too crazy but in the end it's just a workaround, when instead argon has a way to insert a secret. ------------------------------------------------------------------------ [2019-03-28 19:58:51] jedisct1@php.net Halite is very simple to use and does password hashing+encryption: https://github.com/paragonie/halite/blob/master/doc/Classes/Password.md ------------------------------------------------------------------------ [2019-03-28 19:50:45] davidapgilman at gmail dot com I concur with the OP - the best way to use a pepper with Argon2 is to use the built in "secret" parameter. There are workarounds as suggested, but the most elegant, audited, and cryptographically secure method is to use the built-in secret parameter as designed. I understand if there are higher priority PRs, but it's negligent and ignorant to choose to leave off a built-in security feature of the PHC winner. You're encouraging developers to roll their own encryption at worst, and forcing them to choose between a number of non-intuitive workarounds at best. I'd like to re-request this feature. ------------------------------------------------------------------------ [2018-06-16 16:22:53] phpdoc at mail dot my1 dot info @jedisct1 last time I checked, the ability of using arbitrary salts wasnt available for PASSWORD_ARGON2I and only for PASSWORD_BCRYPT and even that is deprecated. and as stange already says it is exposed by other languages and on top of it, it is a part of argon. why should one go with playing on the salt using a pseudorandom function with both a self made salt and a secret if argon can accept secrets by itself and just use that? also it's probably more secure than a self-built workaround anyway. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=75388 -- Edit this bug report at https://bugs.php.net/bug.php?id=75388&edit=1

« previous php.bugs (#220259) next »