On 27 Dec 2009, at 20:46, Benoit Chesneau wrote: > On Sun, Dec 27, 2009 at 8:05 PM, Chris Anderson <[email protected]> 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.
If the default behaviour of CouchDB is to pop up the ugly basic auth window nobody is going to use it. Chris advocates a solution where CouchDB doesn't force login window at the expense of *potentially* having library authors jump through an extra hoop. If it is going to turn out that way, I'd +1 that, but let's first figure out if these solutions are mutually exclusive. Cheers Jan -- > >>>>>> 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 >
