couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Klaus Trainer (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-1060) CouchDB should use a secure password hash method instead of the current one
Date Sat, 05 Feb 2011 19:27:30 GMT

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

Klaus Trainer commented on COUCHDB-1060:
----------------------------------------

Base64 is already used for basic authentication. A reason for using the hash function for
cookie authentication is that you don't wanna have your password to be persitently stored
in cleartext/Base64. If somebody manages to steal your cookie with that hash, she still doesn't
have the password, and the hash is worthless anyway as soon as the session is closed/expired.

If you need reasonable security, talk with your couch only through SSL and use a password
that's not in a dictionary.

The concern about somebody doing dictionary attacks on all _user DB entries can be met by
restricting access to it.

Btw., AFAIK, an authentication cache is already used.

> 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

        

Mime
View raw message