nickva commented on PR #4814:
URL: https://github.com/apache/couchdb/pull/4814#issuecomment-1773480674
> I deliberately separated into multiple commits but I feel adding
pbkdf2-sha256 with high iterations without the cache would lead to problems for
folks.
>
The cache would be for the increased default iteration count? It would make
sense to add it even for a sha1 higher iteration count. sha256 is a bit more
expensive but still within the same order of magnitude as sha1.
```
> timer:tc(fun() -> crypto:pbkdf2_hmac(sha256, <<"password">>, <<"salt">>,
10000, 32) end).
{7010,
<<94,192,43,145,164,181,156,111,89,221,95,190,76,166,73,
236,228,250,133,104,205,184,186,54,207,65,66,...>>}
> timer:tc(fun() -> crypto:pbkdf2_hmac(sha, <<"password">>, <<"salt">>,
10000, 20) end).
{4951,
<<162,194,100,97,134,130,132,116,183,84,89,26,84,124,24,
241,50,216,141,116>>}
```
> the password cache could be optional, I could add a toggle so admins that
want to can disable it. given that the work effort for a cached item is quite
small (though not as small as the single-pass sha1) I didn't think it was
necessary, but it's also easy to add.
The main concern there is that concurrent requests will check the single ets
table, which also ends up being updated constantly with the atime `accessed`
operations. It seems if users have generated random 128 bit salts and password
for API keys, they should be able to use a sha256 or sha512 with a low
iteration number to avoid an extra hash and ets table check.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
