[
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
