couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: authentication cleanup
Date Sun, 27 Dec 2009 19:46:44 GMT
On Sun, Dec 27, 2009 at 8:05 PM, Chris Anderson <jchris@apache.org> wrote:

>
> 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.

Well software people aren't only people that use CouchApps. About the
popup, as I said the only way we (and mainly jason) found was to pass
another header to couchdb like it is with cookie auth.

>
> 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
> practice.
>
>

I'm not sure what do you mean by aesthetic here, that's not really my
point although I sure don't really care about aestheticism :)  I think
we just have to make sure that it doesn't break expected behavior by
other http clients.

>>>>> 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
> patch.
>
> It would be worth it to start another thread about per-database reader
> ACLs, which are the solution to this problem.
>

my point was just to say that until that you can't store sensitive
data such as oauth credentials in userdb :) Sry was not totally clear.
+1 for another thread.

>>>>>
>>>> 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.

Maybe we could start by using sha256. or more. I will have a look on
what could be done about it.


> 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
> credentials.

The node was just the start to create an id on one node and also to
make sure userid is unique outside a trusted environnement. I didn't
see it like something that need to be changed across replication.
Since you made the prefix configurable, the pb is mostly solved
anyway. For non trusted environment prefix could be anything.


- benoit

Mime
View raw message