[
https://issues.apache.org/jira/browse/COUCHDB-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13902588#comment-13902588
]
Isaac Z. Schlueter commented on COUCHDB-2066:
---------------------------------------------
Before:
{
"_id": "org.couchdb.user:user",
"_rev": "1-25a11cd57475355eaaa6ce92fd16de86",
"roles": [],
"type": "user",
"salt": "salt",
"password_sha": "11f5639f22525155cb0b43573ee4212838c78d87"
}
After:
{
"_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: https://issues.apache.org/jira/browse/COUCHDB-2066
> 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:
> https://twitter.com/janl/status/434818855626502144
> https://twitter.com/izs/status/434835388213899264
> https://twitter.com/janl/status/434835614790586368
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
