couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nuutti Kotivuori (JIRA)" <>
Subject [jira] Commented: (COUCHDB-1060) CouchDB should use a secure password hash method instead of the current one
Date Sat, 05 Feb 2011 21:23:30 GMT


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:
>             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.)

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message