Enable wider control of PBKDF2

[DUG-nick]

In order to comply the recommendations of OWASP I would like to change the hashing algorithm of CouchDB to a HMAC-SHA-256. Currently it only seems possible to set iterations.

I looked at the latest docs, but could not find any setting to set the appropriate value.

For now I will go about using a third party authentication approach, but would like to use the CouchDB auth service.

Summary

I think it is all said. Just for completeness, of course I looked through google, the docs, the issues here and the code befor opening this issue. Please don't be too hard, if I missed something.

Desired Behaviour

Ok, so from the code I tried to read as prep for this comment, I figured, that probably the hashing is always happening in plain sha1. If one could configure something like

[chttpd_auth]
iterations = 310000
hashfunc = SHA256

FIPS-140 compliance could be achieved.

Possible Solution

Ok, I do not know any erlang and are just trying to identify where a possible starting point could be.

In the following lines sha is used (I think as a variable), but I cannot figure out, where it is set:

https://github.com/apache/couchdb/blob/15cbb5502503c6e4d786bf0a85b7c225ccd14f71/src/couch/src/couch_passwords.erl#L26 https://github.com/apache/couchdb/blob/15cbb5502503c6e4d786bf0a85b7c225ccd14f71/src/couch/src/couch_passwords.erl#L46 https://github.com/apache/couchdb/blob/15cbb5502503c6e4d786bf0a85b7c225ccd14f71/src/couch/src/couch_passwords.erl#L146 https://github.com/apache/couchdb/blob/15cbb5502503c6e4d786bf0a85b7c225ccd14f71/src/couch/src/couch_passwords.erl#L160

On the other hand for JWT support mutiple algorithms must be supported. Otherwise "alg": "HS256" could not be verified. Must be somewhere in here:

https://github.com/apache/couchdb/blob/0059b8f90e58e10b199a4b768a06a762d12a30d3/src/jwtf/src/jwtf.erl

Additional context

From what I understand reading through password storage recommendations, the current default settings (10 iterations) and the flexibility of configuration are neither secure by default nor configurable to compliance.

Kind regards, Nick

EDIT:

• Figured out that with PBKDF2 no pepper is used.

[rnewson]

You are correct that the iteration count is too low (the previous scheme is a single pass SHA1, which is as low as it goes).

the blocker here, for increasing iterations or for switching to sha256 or bcrypt/scrypt/yescrypt is that many tools use basic auth, rather than acquire a session cookie, so the desired auth time penalty of 0.5 - 1.0 sec renders the database unusable. There needs to be some more nuanced plan.

[DUG-nick]

While I am thinking about this issue, I was wondering: would it be feasible for basic auth to generate a personal access token, as it is common practice with Github.

On the other hand, it would still be fantastic, if the security architect of any tool utilizing CouchDB could evaluate the risks and performance penalties for their own. So I think making the whole thing configurable would not hurt the system, but rather improve usability.

For now, the only real alternative I can find is a JWT approach with a separate user management. But when synchronizing with a per_user approach, I see a strong potential for error here. It would be great to have couch as kind of the single source of truth in this context.

Does anyone have some other feasible workaround idea?

[fynnlyte]

Does anyone have some other feasible workaround idea?

I'm using the _users - DB to only store random session tokens with random passwords. The users' login credentials are managed in a separate DB. I'm using (and maintaining) couch-auth for that purpose. The config has an option (security.iterations) to control the number of pbkdf2 iterations for passwords.

[nickva]

We have implemented PBKDF2 with SHA-256 with a cache mitigating the larger iteration counts in https://github.com/apache/couchdb/pull/4814

Closing as completed. This should be in the next 3.4 release.