couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Isaac Z. Schlueter (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-2066) Don't allow stupid storage of passwords
Date Sun, 16 Feb 2014 00:06:20 GMT


Isaac Z. Schlueter commented on COUCHDB-2066:


   "_id": "org.couchdb.user:user",
   "_rev": "1-25a11cd57475355eaaa6ce92fd16de86",
   "roles": [],
   "type": "user",
   "salt": "salt",
   "password_sha": "11f5639f22525155cb0b43573ee4212838c78d87"


   "_id": "org.couchdb.user:user",
   "_rev": "1-25a11cd57475355eaaa6ce92fd16de86",
   "password_scheme": "pbkdf2sha",
   "iterations": 10,
   "roles": [],
   "type": "user",
   "derived_key": "298cab86ba2a1520a3cfbd0891281371a1eaa95a",
   "salt": "salt"

The data actually pbkdf2'ed is the password_sha, which is then compared with the salt and
supplied password.

Let N be the security level of having no password hashing at all.
Let S be the security added by using sha/salt hashing.
Let P be the security added by using pbkdf2 hashing.

One can argue that S is not sufficient for storing passwords, and P is.  However, S is clearly
greater than N, and it seems obvious that P+S is greater than P or S alone.

Even after brute-forcing the derived_key, I still now have to brute-force the salted sha.
 Granted, that's a much easier task, but it still can't be LESS secure than using a salted
sha on its own, and it's just as trivial to compare a supplied credential against.

> Don't allow stupid storage of passwords
> ---------------------------------------
>                 Key: COUCHDB-2066
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>            Reporter: Isaac Z. Schlueter
> If a password_sha/salt combination is PUT into the _users db, wrap that up in PBKDF2.
> Discussion:

This message was sent by Atlassian JIRA

View raw message