[
https://issues.apache.org/jira/browse/COUCHDB-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991063#comment-12991063
]
Nuutti Kotivuori commented on COUCHDB-1060:
-------------------------------------------
This issue is about using something else than plain SHA hashing for: a)
password hashing in couchdb configuration file, eg. local.ini, b) password
hashing in _users database on disk storage. Cookie authentication hash method
probably has a vulnerability as well, but that is something separate to solve
and it is not what I wrote about here. Also I am not talking about online
authentication attacks which are done through remotely exposed interfaces, but
offline attacks that are possible when hashed passwords are obtained by some
means.
If access restrictions to _users database and configuration file are in place,
the passwords stored there might just as well be in plaintext - which would be
fine by me. Yet they aren't, which leads me to believe somebody thinks there is
some actual security given by the hash method used in those places by CouchDB.
So, to be clearer in my suggestion, I suggest the either of two options:
1) use a standard slow hash function instead of current SHA-1 solution for
storing passwords
2) store passwords in plaintext, encoded in base64 (to prevent accidental
exposure if shown to an admin)
The current solution gives users a false sense of security and gains very
little in practice.
> CouchDB should use a secure password hash method instead of the current one
> ---------------------------------------------------------------------------
>
> Key: COUCHDB-1060
> URL: https://issues.apache.org/jira/browse/COUCHDB-1060
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core
> Affects Versions: 1.0.2
> Reporter: Nuutti Kotivuori
> Priority: Minor
>
> CouchDB passwords are stored in a salted, hashed format of a 128-bit salt
> combined with the password under SHA-1. This method thwarts rainbow table
> attacks, but is utterly ineffective against any dictionary attacks as
> computing SHA-1 is very fast indeed.
> If passwords are to be stored in a non-plaintext equivalent format, the hash
> function needs to be a "slow" hash function. Suitable candidates for this
> could be bcrypt, scrypt and PBKDF2. Of the choices, only PBKDF2 is really
> widely used, standardized and goverment approved. (Note: don't be fooled that
> the PBKDF2 is a "key derivation" function - in this case, it is exactly the
> same thing as a slow password hash.)
> http://en.wikipedia.org/wiki/PBKDF2
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
