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:
[EMAIL PROTECTED]: ~ $ htdigest -c auth all nslater
Adding password for nslater in realm all.
New password:
Re-type new password:
[EMAIL PROTECTED]: ~ $ 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.
