Mailing-List: contact couchdb-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <FEC771A6-9020-4C30-99A2-C4591B3066E1@apache.org>
From: Damien Katz <damien@apache.org>
To: couchdb-dev@incubator.apache.org
In-Reply-To: <20081022200554.GA17863@bytesexual.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: new CouchDB feature: Admin accounts
Date: Wed, 22 Oct 2008 17:15:27 -0400
References: <ABC27565-824A-47EF-9BE4-618E4F4CEFBF@yahoo.com>
 <20081022200554.GA17863@bytesexual.org>


On Oct 22, 2008, at 4:05 PM, Noah Slater wrote:

> Damien,
>
> Fantastic stuff, this is a great feature!
>
> On Wed, Oct 22, 2008 at 01:13:22PM -0400, Damien Katz wrote:
>> The admin checking uses HTTP basic authentication, we'll need to
>> eventually support SSL to make this secure or support a more secure
>> authentication standard.
>
> I presume that for now, SSL can be added with a reverse proxy.
>
>> When CouchDB starts it will find these new passwords and then hash  
>> them:
>>
>> [admins]
>> admin = -hashed-d6bdc9039b19e41051eb1b94ea8ef905b1a11e2e
>> ,b53ce4e92ad24ad8fc14feadb58d8b60
>> damien katz = -hashed
>> -2f3e9eea97e44b2bb09b56d3b1d66a41f0a74be2,6c37137b479369759e8dc591573b0599
>>
>> /end
>>
>> The hashed password line consists first of "-hashed-" then 2  
>> hexadecimal
>> encoded numbers separated by a comma, the 160 bit sha hashed  
>> password +
>> salt 160 bit sha hash, and then the 128 bit salt (a UUID):
>>
>>  user name = -hashed-%160bit hashed value%,%128 bit salt%
>>
>> So the only restrictions on passwords is they shouldn't start with "-
>> hashed-" and can't contain newlines.
>
> I don't like the idea of keeping passwords in the configuration file  
> like this.
>
> * Having CouchDB update the configuration file feels like "magic" to  
> me.
>
> * The hashed values seem a little long, and hard to manage.
>
> * Restricting the content of the passwords (to avoid problems  
> detecting new
>   passwords) seems a little troublesome. How would it be enforced?
>
> * Keeping passwords and sundry configuration together seems  
> troublesome.
>
> Instead, could I suggest that we follow Apache httpd and use a  
> digest file?
>
> Apache ships with a utility called "htdigest" that should be no  
> problem to ship
> or find on the system, depending on setup. Here is an example of its  
> use:
>
>  nslater@bytesexual: ~ $ htdigest -c auth all nslater
>  Adding password for nslater in realm all.
>  New password:
>  Re-type new password:
>  nslater@bytesexual: ~ $ cat auth
>  nslater:all:49e0297565847b5e586a3342657eb99a
>
> CouchDB could check for this file on startup in its configuration  
> directory.
>

Sounds good If someone wants to hook this up. It was easier to write  
this one that deal with the dependency.


> As a system administrator I could then change the ownership or  
> permissions of
> the password file so that only the `couchdb` user could read it, but  
> open up the
> general configuration file for anyone in the `admin` group, for  
> example.
> It's important to remember that even hashes can be "reverse  
> engineered" with
> rainbow tables to retrieve the original passwords, which is a  
> security concern
> if the hashes are kept in a place readable by more users than is  
> necessary.
>

Actually this is immune to rainbow tables. It uses a per password salt  
(128 bit UUID generated by the crypto lib). Other than using larger  
hash outputs and salt, this is about as secure as hashing can get.

The only weakness I can think of is in the file systems, where the  
original unhashed password is still available in an undo log, or in a  
freed disk block.