Benoit,
The .ini file suggestion seems a good idea, as it allows for pluggable
password hash validation. Now we're thinking about OpenLDAP schemes, but
tomorrow someone might suggest or require something else.
About the JSON object, containing the hash scheme in an attribute and the
hash in a different one, I'm not 100% sure about it. Usually the scheme,
password hash and used salt (if any) travel in the same string. Take a look
at OpenLDAP:
$ slappasswd -s 'teste_password123' -h '{SSHA}'
{SSHA}Pmnj6Jg3CBccqLuYttGMfTYh1GKMLLyC
$ slappasswd -s 'teste_password123' -h '{SMD5}'
{SMD5}ojYaLtvJga+4hJqMSgi34JGUV/8=
and at RFC 3112 ( http://www.ietf.org/rfc/rfc3112.txt ) -
SHA1$RzqH67DY3uQ=$atAcDs1eS+IJwPy7V4UDXEoBrDI=
I would prefer having a .ini file with:
[couch_httpd_auth]
password_hash_scheme = -hashed- ; the default scheme to use for hashing
passwords
password_validators= {couch_httpd_auth, hashed_password_validator},
{couch_httpd_auth, openldap_password_validator}
[password_hash_creators]
; scheme = {module, function}
-hashed- = {couch_httpd_auth, hash_password}
{SSHA} = {couch_httpd_auth, openldap_hash_password}
{SMD5} = {couch_httpd_auth, openldap_hash_password}
To validate a user supplied password, we would execute each
password_validator in turn until one of them succeeds. Exactly like we do
now with the authentication_handlers.
Each password validator would receive 2 paremeters: the user supplied
password and the password hash previously computed.
Each password hash creator would receive 2 parameters: the scheme and the
password to hash.
In a _users doc, we would drop the attribute "salt" and rename
"password_sha" to "password_hash".
What do you think?
On Fri, Feb 12, 2010 at 1:20 PM, Benoit Chesneau <bchesn...@gmail.com>wrote:
> On Fri, Feb 12, 2010 at 7:10 AM, Chris Anderson <jch...@apache.org> wrote:
> > On Tue, Feb 9, 2010 at 2:52 PM, Chris Anderson <jch...@apache.org>
> wrote:
> >> Devs,
> >>
> >> I've been getting a lot of feedback about the authentication &
> >> authorization work that I did over the holidays and over the last few
> >> weeks. There are also some enhancements I've been thinking about for a
> >> while. Here's a quick list of what I see as the important things to
> >> do. I'm not concerned here with releases / feature freeze etc as in my
> >> opinion CouchDB development is expected to continue even after we
> >> reach 1.0.
> >>
> >> 1) Extensible password storage.
> >>
> >> Thanks Brian Candler for the links to the OpenLDAP style of storage. I
> >> think we should do this asap so we don't have to worry about backwards
> >> compatibility with the current storage mechanism until the end of
> >> time. The relevant message:
> >> http://permalink.gmane.org/gmane.comp.db.couchdb.devel/7588
> >
> > I'm helping Filipe Manana with an implementation of this, which will
> > be backwards compatible with existing admin passwords (stored in
> > config). We won't try to be backwards compatible with old _users dbs
> > (it should be simple to write an upgrade script if you have crucial
> > data). This doesn't need to block 0.11 but it could go in 0.11.1 as
> > it'd be nice to get it out there for people who want better crypto.
> >
> >>
>
> Actually I think I wouild prefer a json object so we don't have to
> parse string a such
>
> {
>
> "auth-type": "brypt-sha1",
> "key": ...
> }
>
> and in ini
>
> [crypt-handlers]
> { "bcrypt-sha1", "couch_httpd_auth", "brcrypt_sha1_encode",
> "brcrypt_sha1_decode" }
>
> Somethink like it. Which is basically the same as having all in one
> string but is more jsonful. Also it remove the need to parse the
> string or do more pattern matching than needed.
>
> Is there any ticket open about it ?
>
> - benoît
>
--
Filipe David Manana,
fdman...@gmail.com
PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
