Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of terryzsmith@gmail.com
 designates 209.85.216.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CC71DC5D-671A-43AF-8190-00D4F7486DBC@apache.org>
References: <775360A4-E5B2-464C-AC78-3AF44B7B2F64@apache.org>
	<CALbocOkJJq3Vtw4pe0okCQOEEyKTXY5t0VKonxfP657On4WR0Q@mail.gmail.com>
	<3E9869BA-22E7-4645-9FE8-4CE0F31A5C57@apache.org>
	<591473D8-47C4-486E-84F0-D837D577D0C3@apache.org>
	<CAAL6JQg2D1vQw0TrB5_wk-mZ2-XUhrtJBPRD5CBr13eU1SOeyw@mail.gmail.com>
	<915624D6-228D-48D9-81A0-956FA2B37361@apache.org>
	<CAMGtuKEQ_TxZCaCCVerfBFEfVcW5J=FWzgLiwUjqJRKtMD9Vog@mail.gmail.com>
	<89C1BF6C-93EA-45E8-AE66-6B8067A1B6F2@apache.org>
	<64A8B61A-E27D-4AD4-9D1A-81E64B6C4F2B@apache.org>
	<B0BFC7FA-6107-4993-99A3-F6E28F2C09D7@apache.org>
	<3D5914FE-27E9-4EED-9FAF-CB122AC2E248@apache.org>
	<CAJNb-9rV0RzgEFfM24Hwzio03iqdo6oOx6TAzWi1LygT9AO4GQ@mail.gmail.com>
	<BF725BED-C687-4812-BE2C-B30401166484@apache.org>
	<CC71DC5D-671A-43AF-8190-00D4F7486DBC@apache.org>
Date: Tue, 16 Aug 2011 18:14:16 -0400
Message-ID: 
 <CAFPYc+rDoccOMD8Wv7Ys1093Lxk6iJ5cu+VehFQY_LUfgSwLgw@mail.gmail.com>
Subject: Re: Configuration Load Order
From: Terry Smith <terryzsmith@gmail.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=20cf3079bdd253fc0904aaa6b309

--20cf3079bdd253fc0904aaa6b309
Content-Type: text/plain; charset=ISO-8859-1

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
> --
>
>

--20cf3079bdd253fc0904aaa6b309--