While we're on the subject of password hashing I discovered an inconsistency with respect to the password salt deserialization in the current implementation. I haven't looked at your new code, Bob, so I don't know if hex deserialization is relevant to it or not, but I wanted to pass this information along.
Here's what I found. A password's salt is defined as "(128 bit UUID generated by the crypto lib)" from here http://mail-archives.apache.org/mod_mbox/incubator-couchdb-dev/200810.mbox/%[email protected]%3e. The salt starts out that way but then it is converted to a string representation of the bytes via couch_util:to_hex(). When the hash of the password + salt is taken the bytes for the character codes of the string version of the 128 bit UUID are used as the salt. I'll use a 3 byte salt for an example. The bytes are 16#3f 16#db 16#ef to_hex() returns "3fdbef" list_to_binary() then converts the string into <<"3fdbef"">>... this is the list of character codes for each character in the string. The bytes are 16#33, 16#66, 16#64, 16#62, 16#65, 16#66. This is the actual salt. I discovered this because I am setting up an admin's name, hash and salt in CouchDB's local.ini with an external program (because of my organization's security requirements), but authentication in CouchDB failed with a different hash result. I did not convert my 16 byte salt to a string and then use those bytes (character codes) for the salt. Once I did authentication in CouchDB succeeded. The end result is harmless so I worked on the rest of my project and would report it at a later time to be documented if needed. Coincidentally, I have some time now and your proposal spurred me to finally report it. --Terry On Wed, Jul 6, 2011 at 9:10 AM, Robert Newson <[email protected]> wrote: > Making it pluggable is probably not much more work but I have to point > at that "use sha256" is an inadequate description of a secure password > hashing protocol. > > B. > > On 6 July 2011 14:05, Benoit Chesneau <[email protected]> wrote: > > On Wed, Jul 6, 2011 at 2:43 PM, Robert Newson <[email protected]> > wrote: > >> All, > >> > >> Our current password hashing scheme is weak. In fact, it's regarded as > >> weak as plaintext. I'd like to change that. > >> > >> Some time ago I wrote some code to implement the PBKDF2 protocol. This > >> is a cryptographically sound means of deriving a key from a password. > >> The output is also usable as a password hash. An important part of the > >> protocol is that the work factor can be increased by increasing the > >> loop count. Additionally, it is not tied to a specific digest > >> algorithm. All these points are not true of the sometimes proposed > >> alternative called 'bcrypt' which I do not recommend. > >> > >> I would like this to go into CouchDB 1.2. New passwords, and updated > >> passwords, from 1.2 onwards would use the new scheme, but 1.2 will, > >> obviously, be able to verify the current style. This work will take > >> place within couch_server where hash_admin_passwords currently lives. > >> > >> The PKBDF2 code is here: > >> https://github.com/rnewson/couchdb/tree/pbkdf2. It passes all the test > >> vectors. > >> > >> The ticket for this work is > https://issues.apache.org/jira/browse/COUCHDB-1060 > >> > >> B. > >> > > That sounds good. I would prefer however a customizable hashing method > > for passwords so we can change it easily depending the target. Some > > administrations for example require that you use some methods (like > > sha256 in europe) and it would be very useful. > > > > - benoît > > >
