couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1060) CouchDB should use a secure password hash method instead of the current one
Date Tue, 10 May 2011 23:01:47 GMT


Chris Anderson commented on COUCHDB-1060:

The current implementation avoids a special server side API for creating documents in the
_users database. Architecturally, I am fine with a special API for the user's database --
however it may make sense to keep it in the "shape" of the CouchDB API. So for instance creating
a user would go through an _update function, which could compute the salt and hash, before
storing in the _users db.

The alternative would be to define a custom endpoint for POST requests to create documents
in the user db, and then we'd have to bike-shed and document that API.

However if someone wants to write all that code, I won't stop you. If energy is going to poured
in here, the other thing we should consider is a "write-only" database mode, so that users
can PUT and POST, but not GET. In this case the _update function would still be a good way
to do the salt and hashing. Anyway, this is a distinct topic but related.

> 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
>            Assignee: Robert Newson
>            Priority: Minor
>             Fix For: 1.2
>         Attachments: pbkdf2.erl, pbkdf2.erl
> 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