Req #75388 [Com]: Argon2: Add secret/key
| From: | phpdoc at mail dot my1 dot info | Date: | Sat, 16 Jun 2018 16:22:55 +0000 |
| Subject: | Req #75388 [Com]: Argon2: Add secret/key | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-215756@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
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.
Previous Comments:
------------------------------------------------------------------------
[2018-03-29 15:08:56] jedisct1@php.net
If you really need this, don't store the salt itself. Generate and store a random
s, and use prf(k, s) as the salt. This is equivalent to adding a secret
key to the initial Argon2 state.
A major drawback is the fact that keys cannot be rotated.
A way better approach is to encrypt the hashes. You may also want to add an authentication tag that
includes the salt and parameters, to prevent resources starvation if the parameters get modified
while still allowing parameter updates.
Authenticated encryption is beyond the scope of a password hashing function. Combining both in a
simple way is an API's responsibility.
libsodium 2.x will use the libhydrogen API, but the password hashing API might be backported to the
1.x branch: https://github.com/jedisct1/libhydrogen/wiki/Password-hashing
------------------------------------------------------------------------
[2018-03-29 14:07:22] stange at digitalriver dot com
The secret is an important feature with argon2. Other languages expose it.
------------------------------------------------------------------------
[2018-03-29 14:07:19] stange at digitalriver dot com
The secret is an important feature with argon2. Other languages expose it.
------------------------------------------------------------------------
[2017-10-17 16:20:53] cmb@php.net
Feedback has been provided, so opening again.
Assigning to Frank, since he implemented the argon2 password hashing for PHP,
and apparently doesn't like non-replaceable keys[1]. Besides, using the secret
key doesn't appear to work with argon2*_hash_encoded().
[1] <https://github.com/P-H-C/phc-winner-argon2/issues/222>
------------------------------------------------------------------------
[2017-10-17 09:55:31] phpdoc at mail dot my1 dot info
@requinix
as daverandom points out, I want to have PHP expose the secret which is a part of argon2.
while while you could work around this by attaching a secret by appending, HMAC, or whatever, you
could probably also do argon2 in userland, technically, not that it's a good Idea though and
it's nice that we have it in PHP7.2
my point is just if argon2 does have something like this already nicely defined, as part of its own
standard, why not use it?
@dave, well the salt is a little bit different than an extra secret.
the salt is most notably a RANDOM piece of data attached to some data before it is thrown into the
hash and the salt is essentially visible for everyone who can see thze hash, and is to throw rainbow
tables into oblivion. and since a salt is supposed to be random, I think it is not a bad Idea to
throw the manual setting of the salt away, because there may certainly people who use the XKCD
Random number generator.
a Pepper in contrast is usually a special secret value which is stored not in the database but
somewhere else (config file environment, whatever you think is best) and should have a certain
complexity to be effective, and its point is to have something that even if an attacker can get the
hashes via some database leakages they wont be just getting around and calculating all the
passwords, even if these are really ugly ones like 123456 because without the secret, an attacker
would be getting nowhere.
------------------------------------------------------------------------
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