couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terry Smith <terryzsm...@gmail.com>
Subject Re: Configuration Load Order
Date Tue, 16 Aug 2011 22:14:16 GMT
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-C4591B3066E1@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 <jan@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
> --
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message