Re: authentication cleanup
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. One question is how to manage system roles such as _admin. My thinking is that the users db validation function will forbid roles starting with underscore from being stored on user's documents. Instead, when Couch loads a user from the db, it will cross-reference the user with the list of node and db admins, and apply the _admin role when appropriate. This way we can avoid having more than one distinct type of user in the system. This should also allow us to have more system roles (prefixed with underscore) in the future. Not sure to follow here.Do you plan to remove admins from ini ? I would be to keep them. They are like super users. We could create another class of users for that. Maybe _staff to follow unix terminology? I don't plan to remove admins from the config. The _admin role will be applied to users in the users db, based on the config setting. (Also, if you don't use the user's db, you will not notice any change at all.) Another _role that we could add in the future is a _replicate role, which normal users could have the option to run replication under. This would allow validations to enforce things like author names, without requiring users to run replication as _admin and expose design docs to potential unwanted changes. I'm also thinking that the /_session handler should speak JSON primarily (but I'll probably leave in the ability to handle form-encoded request bodies as well). We could just detect http headers and provide the needed response for that. Keeping the form encoded would be good. It's already used in some applications. I think we'll end up supporting both, but I want to get the JSON API in place and well tested. The _session by form is already in place and used in some apps. I'm full for a json api, but also I think that both form and json ap should be supported as well and since orm api is already in place and used by apps, it should stay in place and json api just added as another alternative. One reason for this is that sometimes you don't want your app speak json but just have an easy way to login. Still there aren't only couchapps that use couchdb. 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. 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. None of what I'm doing should change the oauth handlers. oauth is a problem here if it's in a public db. I agree hiding the users db would be more secure, but the current codebase uses a public users db. I've got to draw the line for this patch somewhere. Should we eventually get per-db reader ACLs, they'll be perfect for making this a little more secure. In any case oauth credentials shouldn't be public. What about if someone steal the key and use it to log ? One problem I've run into is how to enforce that logins are unique within the users db. The simple answer is to make the username into the docid. This has the upside that if 2 sites are replicated together, any duplicated user docs will go into a conflict state immediately. I think this is better than having the ambiguity come up at login time, when it's not clear which user document to test the password against. If we do login-as-docid, then we can encourage people to use email addresses as login tokens, which should help avoid spurious conflicts when sites are merged. The other option is to keep doing what we do now, and run a view query to see if the user name has been taken before saving the document. This has the advantage of mostly working while avoiding replication conflicts. However, as I said above, I think we want those replication
Re: authentication cleanup
On Sun, Dec 27, 2009 at 10:47 AM, Benoit Chesneau bchesn...@gmail.com wrote: The _session by form is already in place and used in some apps. I'm full for a json api, but also I think that both form and json ap should be supported as well and since orm api is already in place and used by apps, it should stay in place and json api just added as another alternative. One reason for this is that sometimes you don't want your app speak json but just have an easy way to login. Still there aren't only couchapps that use couchdb. s/since orm api/since form api
Re: authentication cleanup
On Sun, Dec 27, 2009 at 8:05 PM, Chris Anderson jch...@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
Re: Updating the CouchDB roadmap
On Thu, Dec 3, 2009 at 8:29 PM, Noah Slater nsla...@tumbolia.org wrote: Hey, As part of the release procedure, this is a request to update the roadmap document: http://couchdb.apache.org/roadmap.html Please comment on what should be added, and what should be removed. After a we reach consensus, I will update the roadmap. Thanks, Noah This a quick summary of what have been proposed on this thread. If I forgot one, sorry, and don't hesitate to update :) I'm not sure all of this is in jira. But maybe once they are, we could extract a roadmap from it ? *) New tasks: - Support for compressed attachments - authorization per database - a global notification handler which would allow an indexer (or anything else) to listen changes without opening a connection per db. Some work started here - Better RFC 2616 compliance: some work started, couchdb webmachine branch on github and other commits - Windows support for compaction - design doc refactoring: work started by jchris - Account's tab for Futon *) Old tasks that could be removed from the roadmap : - Continuous replication - Pure tail-append storage - Update API to parse client requests in JavaScript - Cookie authentication support - Windows build supports Date for 0.11: 1/02/20010 - benoit
Re: authentication cleanup
On Sun, Dec 27, 2009 at 11:46 AM, Benoit Chesneau bchesn...@gmail.comwrote: On Sun, Dec 27, 2009 at 8:05 PM, Chris Anderson jch...@apache.org wrote: 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. I am just jumping in late here, so forgive me if this has been discussed. What about using bcrypt? Which is *designed* to be a slow hashing algorithm so that you dramatically reduce the ability to conduct brute force attacks. sha1, sha256, etc are designed to be fast, which if you gain access to the raw hashes is a bad thing. The idea is to make brute force attacks as computationally expensive as possible, while not impeding normal usage. for general context see : http://bit.ly/7nR09X http://bit.ly/91a05S And it seems like Adam K. has brought this up before as an option: http://bit.ly/7nxlA1
Re: authentication cleanup
On Sun, Dec 27, 2009 at 10:09 PM, Glenn Rempe gl...@rempe.us wrote: On Sun, Dec 27, 2009 at 11:46 AM, Benoit Chesneau bchesn...@gmail.comwrote: On Sun, Dec 27, 2009 at 8:05 PM, Chris Anderson jch...@apache.org wrote: 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. I am just jumping in late here, so forgive me if this has been discussed. What about using bcrypt? Which is *designed* to be a slow hashing algorithm so that you dramatically reduce the ability to conduct brute force attacks. sha1, sha256, etc are designed to be fast, which if you gain access to the raw hashes is a bad thing. The idea is to make brute force attacks as computationally expensive as possible, while not impeding normal usage. for general context see : http://bit.ly/7nR09X http://bit.ly/91a05S And it seems like Adam K. has brought this up before as an option: http://bit.ly/7nxlA1 also there is already some erlang code : http://github.com/skarab/erlang-bcrypt - benoit
Re: authentication cleanup
On Sun, Dec 27, 2009 at 1:33 PM, Benoit Chesneau bchesn...@gmail.com wrote: On Sun, Dec 27, 2009 at 10:29 PM, Benoit Chesneau bchesn...@gmail.com wrote: also there is already some erlang code : http://github.com/skarab/erlang-bcrypt - benoit Ah that what adam mentionned too. Cool -- I'll have to look into bcrypt. A quick search doesn't reveal a JavaScript implementation, but hopefully there's one somewhere. For now I'll keep using sha as it doesn't really matter which one we use for prototyping purposes. -- Chris Anderson http://jchrisa.net http://couch.io
