You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Damien Katz <da...@yahoo.com> on 2008/10/22 19:13:22 UTC
new CouchDB feature: Admin accounts
I checked a new feature, Admin accounts.
Admin accounts are used for perform admin restricted actions like
creating/deleting databases and altering the configuration settings.
If there are no admin accounts for a server, then admin checking is
turned off and anyone can perform admin actions.
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.
When the user attempts to perform an Admin action, the browser checks
the user supplied credentials and sees it if matches any admin
account. If not, a 401 Unauthorized error is returned and the HTTP
client can resubmit with proper credentials. When the credentials
match, the action is allowed to proceed.
To turning admin checking on, in the local.ini file, you add an
accounts section, with user name/password pairs, like this:
[admins]
admin = password
damien katz = foo
/end
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.
Once a password is hashed, to change it, reset the password via the
HTTP config api, CouchDB will then automatically hash the password
without restarting. Or edit it by hand by deleting the old hashed
value (everything after the "=") and enter in the new password. Then
restart the server.
Problems/Caveats:
To run the test suite against a server with admin accounts enabled
requires the user to have admin access.
There is a known problem in Futon with Safari, maybe other browsers,
where it doesn't prompt the user for credentials, it just fails the
HTTP request. In Firefox when the tests start to run and the HTTP
client gets the first failure, the user is asked by the browser for
his user name and password, the request automatically retried and all
the tests pass without incident. But in Safari, the tests simply fail
with 401 errors and the user is never prompted for credentials.
A workaround is to do something to force the browser to "log-in" by
trying to view config values, or create a new database. Once logged in
like that, the tests will pass just fine on Safari. We maybe need to
force the log-ins at the beginning of the tests, or provide a Log-in
button somewhere in Futon.
Feedback please.
-Damien
Re: new CouchDB feature: Admin accounts
Posted by Randall Leeds <ra...@gmail.com>.
> 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.
Another argument for htdigest-like tool.
Re: new CouchDB feature: Admin accounts
Posted by Jan Lehnardt <ja...@apache.org>.
Hi,
On Oct 24, 2008, at 16:32, Noah Slater wrote:
> On Wed, Oct 22, 2008 at 05:15:27PM -0400, Damien Katz wrote:
>> Sounds good If someone wants to hook this up. It was easier to write
>> this one that deal with the dependency.
>
> We need someone with C chops for this, looks like the original is
> still
> available floating around the Web:
>
> http://www.polytech.unice.fr/~buffa/cours/internet2000/TD/td2/tools/htpasswd.c
>
> We can't use Apache httpd's version because it depends on the APR.
> I would help, but I don't know the first thing about C.
http://svn.apache.org/viewvc?view=rev&revision=707663
Cheers
Jan
--
Re: new CouchDB feature: Admin accounts
Posted by Noah Slater <ns...@apache.org>.
On Wed, Oct 22, 2008 at 05:15:27PM -0400, Damien Katz wrote:
> Sounds good If someone wants to hook this up. It was easier to write
> this one that deal with the dependency.
We need someone with C chops for this, looks like the original is still
available floating around the Web:
http://www.polytech.unice.fr/~buffa/cours/internet2000/TD/td2/tools/htpasswd.c
We can't use Apache httpd's version because it depends on the APR.
I would help, but I don't know the first thing about C.
--
Noah Slater, http://bytesexual.org/nslater
Re: new CouchDB feature: Admin accounts
Posted by Damien Katz <da...@apache.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.
Re: new CouchDB feature: Admin accounts
Posted by Noah Slater <ns...@apache.org>.
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.
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.
Thanks,
--
Noah Slater, http://bytesexual.org/nslater