On Sun, Dec 27, 2009 at 1:47 AM, Benoit Chesneau <bchesn...@gmail.com> wrote: > Sorry was off, hosting family for christmas. > > - benoit > > On Fri, Dec 25, 2009 at 12:58 AM, Chris Anderson <jch...@apache.org> wrote: >> On Thu, Dec 24, 2009 at 10:16 AM, Benoit Chesneau <bchesn...@gmail.com> >> wrote: >>> On Thu, Dec 24, 2009 at 5:27 PM, Chris Anderson <jch...@apache.org> 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 practice. > 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 patch. 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 "user:jch...@apache.org" >> 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 usern...@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 credentials. Chris -- Chris Anderson http://jchrisa.net http://couch.io
