Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Tue, 10 May 2011 23:01:47 +0000 (UTC)
From: "Chris Anderson (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: 
 <1634053972.1635.1305068507729.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <679185515.1934.1296928530664.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (COUCHDB-1060) CouchDB should use a secure
 password hash method instead of the current one
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/COUCHDB-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031452#comment-13031452 ] 

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: https://issues.apache.org/jira/browse/COUCHDB-1060
>             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.)
> 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