couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: authentication cleanup
Date Sun, 27 Dec 2009 19:05:35 GMT
On Sun, Dec 27, 2009 at 1:47 AM, Benoit Chesneau <> wrote:
> Sorry was off, hosting family for christmas.
> - benoit
> On Fri, Dec 25, 2009 at 12:58 AM, Chris Anderson <> wrote:
>> On Thu, Dec 24, 2009 at 10:16 AM, Benoit Chesneau <> wrote:
>>> On Thu, Dec 24, 2009 at 5:27 PM, Chris Anderson <> wrote:
>> I think it is possible to accept basic-auth when users provide it,
>> without sending the sort of response that triggers the popup in the
>> browser. If you have to have that popup to be RESTful, then I don't
>> want to be RESTful. On a serious note, I can't imagine anyone ever
>> writing a serious CouchApp if the browser-auth-popup is lurking there,
>> ready to ruin the user experience at every turn.
> Basic auth isn't use only by couchapps. Libs need to access to. The
> 401 response which create the popup is needed by libs too.

I haven't yet investigated what it takes to prevent the basic-auth
popup. It will be very hard to convince me that is acceptable to
trigger it. I understand the principles of RESTful service discovery,
I just think they are less important than having software people
actually use. Maybe we'll get lucky and we can have the 401 and avoid
the basic popup. We'll see.

Worst case scenario is application authors avoiding CouchDB's
authentication for aesthetic reasons. Eg: I'd rather have
authentication that is less than perfectly RESTful, that people
actually use, than a perfectly RESTful solution that is unusable in

> The _session by form is already in place and used in some apps.

Agreed. I'm keeping the form-encoded login, and I haven't got around
to adding a JSON login yet.

>>>> In the future, when we implement reader access-control-lists for
>>>> databases, they will be useful to further secure the users DB. For
>>>> now, the users db will be world-readable, which is fine as long as
>>>> no-one breaks the crypto. We're already using strong hashes and long
>>>> salts, so I think we're already relatively secure.
> relatively secure is not enough imo. We should try to make it really
> hard to guess a password and more generally to authenticate. Without
> that couchdb will never be acceped in some projects.

I agree that there we'd like to make an option to restrict read-access
to the users db. I just don't think its part of the work I'm doing on
this patch. The work I'm doing now makes CouchDB more secure (by using
validation functions so that users can't make themselves into admins).

The users db is currently world-readable, so I'm not opening a new
security hole here. Let's fix this. It's just not part of the current

It would be worth it to start another thread about per-database reader
ACLs, which are the solution to this problem.

>>> Not really since salt is available and hash is only sha1. I think we
>>> could make it harder but I agree with a strong encryption we don't
>>> need to hide them.

I'd be happy if someone can work out a stronger cryptographic
solution. I don't think that there's much we can do to make brute
force password guessing harder (aside from hiding the user's db, which
we should do), but I'd be happy to be shown otherwise.

>> So I think I'm gonna switch to docids like ""
>> and "user:Monty4eva". If this is a stupid idea please convince me not
>> to do it.
> why not choosing the erlang way ? We could associate a node name to
> each couchdb node (-sname or -name) which is a dns name. Then all user
> ids could be username@nodename ? Which could be an email but not
> necessarly. I like the approach used by XMPP and jid for that.

Erlang node names don't work because I'd like my username to be the
same across many nodes. Eg, I'd like to be able to replicate my users
db between my laptop and my server, and log into both with the same


Chris Anderson

View raw message