On the subject of a tool to write passwords to CouchDB ini file... A while back I discovered an inconsistency with respect to the password salt deserialization. If password securing is still a salted hash when this tool is made you'll need to take what I found into account because I've done this.
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/%3cfec771a6-9020-4c30-99a2-c4591b306...@apache.org%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. --Terry On Tue, Aug 16, 2011 at 2:33 PM, Jan Lehnardt <j...@apache.org> wrote: > > On Aug 16, 2011, at 8:31 PM, Noah Slater wrote: > > > > > On 16 Aug 2011, at 10:33, Benoit Chesneau wrote: > > > >> Imo we shouldn't at all provide plaintext passwords. Maybe a safer > >> option would be to let the admin create the first one via http or put > >> the hash in the a password.ini file manually. If we are enough kind we > >> could also provide a couchctl script allowing user management, config > >> changes ... ? > > > > This sounds like a decent proposal. Much like you have to use htpasswd to > generate passwords for Apache httpd, we could bundle a script that lets you > generate passwords for the CouchDB ini files, and then forbid the use of > plaintext. This solves both the technical problem (I think?) and helps us > re-enforce better security practices across the board. > > Agreed. > > Cheers > Jan > -- > >
