You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jens Alfke <je...@couchbase.com> on 2011/11/10 23:00:03 UTC
Conflicting password-storage info on the wiki
According to the wiki[1], the documents in the _users database store hashed passwords in “password_sha” and “salt” attributes. But when I look at my actual running server, _users documents don’t have those fields in them, just “name”, “type” and “roles”. Instead, the hashed password seems to live in an [admin] section of the local .ini file, as referred to elsewhere in the wiki[2].
I’m assuming the “Security Features Overview” page [1] is out of date, and the hashed passwords were moved out of the database to make them safer from attack?
If so, what’s the best procedure for adding user accounts programmatically? Post to _config first to set up the password, then add the user document to _users?
—Jens
[1] http://wiki.apache.org/couchdb/Security_Features_Overview#Authentication_database
[2] http://wiki.apache.org/couchdb/Setting_up_an_Admin_account
Re: Conflicting password-storage info on the wiki
Posted by Jason Smith <jh...@iriscouch.com>.
All this s/homology/analogy/
How humiliating!
On Fri, Nov 11, 2011 at 8:00 AM, Jason Smith <jh...@iriscouch.com> wrote:
> On Fri, Nov 11, 2011 at 5:41 AM, Jens Alfke <je...@couchbase.com> wrote:
>>
>> On Nov 10, 2011, at 2:02 PM, Adam Kocoloski wrote:
>>
>>> Heh. No, they're still stored out in the open for anyone to see. Only the server admin passwords are stored in the .ini file. Did you try creating a normal user? As far as I know that documentation is still accurate.
>>
>> Aha, I’ve only got a single admin account on my server
>
> Hi, Jens. Famous last words. :)
>
> Having just an admin (actually, Admin Party) is the traditional (or at
> least, historical) operating mode of CouchDB. (The test suite
> "requires Admin Party" for historical reasons: most of it was written
> when that was the only mode CouchDB had.)
>
>> I can create a normal user by just doing a PUT to _users, but can I create an admin account that way too? Or do I have to modify the config file to do that?
>
> Admins are managed completely differently from user accounts. You
> actually do not need a _users document to make admin requests. All you
> need is an entry in the "admins" config section. (I personally avoid
> mentioning the .ini file. It is an implementation detail to the
> /_config web API.)
>
> That is sufficient to query couch with the _admin role. If you GET
> /_session, you see this:
>
> { ok: true,
> userCtx:
> { name: '<whatever>',
> roles: [ '_admin'] },
> info:
> { authentication_db: '_users',
> authentication_handlers: [ 'oauth', 'cookie', 'default' ],
> authenticated: 'default' } }
>
> You might ask: why not just have normal user accounts with "_admin" in
> the roles. I once asked Chris that question, and he said just in case
> something was deeply broken, you can always log in as the admin. What
> a great example of evolutionary homology! (Homology is bat wings and
> bird wings; fish tails and whale tails). Any Unix sysadmin will tell
> you to keep a plain root user in /etc/password, for when your
> NIS/LDAP/Kerberos fails.
>
> Problem1: You can't grant additional roles to that user. You can't
> give them a couch.app.profile.
> Solution 1: Couch (actually this is 100% implemented in Futon if I
> recall) creates a corresponding document in _users, to store normal
> user stuff
>
> Problem 2: What if the password and salt get out of sync with that in
> the config? (Similarly, what if somebody tries to crack your admin
> password?)
> Solution 2: The document for the admin user omits the password_sha and
> salt fields. They cannot go out of sync with the config, and they
> cannot be seen by unprivileged users.
>
> Side note: Just like Unix and Windows and everything else, we should
> avoid using the admin account whenever possible. You might make an
> operator error in Futon (e.g. click "delete database" instead of
> "compact database"); and you are also vulnerable to XSS attacks. If
> somebody can get javascript into a couchapp you use, they can query
> that couch with your _admin cookie.
>
> P.S. Speaking of homologies, it is time CouchDB adopted something like
> password shadowing. I wish _users was generally inaccessible to
> unprivileged users. You can do this today in the _security object, and
> it works just fine; but users can't create or update their accounts.
> The Ocasta Facebook plugin, and the BrowserID plugin complement this
> with account autovivification. My inbox database patch could help too,
> but it's still an incomplete solution. The point is, Couch, just like
> Unix, can only go so far with a the comprehensive accounts database
> flapping in the breeze.
>
> --
> Iris Couch
>
--
Iris Couch
Re: Conflicting password-storage info on the wiki
Posted by Jason Smith <jh...@iriscouch.com>.
On Fri, Nov 11, 2011 at 5:41 AM, Jens Alfke <je...@couchbase.com> wrote:
>
> On Nov 10, 2011, at 2:02 PM, Adam Kocoloski wrote:
>
>> Heh. No, they're still stored out in the open for anyone to see. Only the server admin passwords are stored in the .ini file. Did you try creating a normal user? As far as I know that documentation is still accurate.
>
> Aha, I’ve only got a single admin account on my server
Hi, Jens. Famous last words. :)
Having just an admin (actually, Admin Party) is the traditional (or at
least, historical) operating mode of CouchDB. (The test suite
"requires Admin Party" for historical reasons: most of it was written
when that was the only mode CouchDB had.)
> I can create a normal user by just doing a PUT to _users, but can I create an admin account that way too? Or do I have to modify the config file to do that?
Admins are managed completely differently from user accounts. You
actually do not need a _users document to make admin requests. All you
need is an entry in the "admins" config section. (I personally avoid
mentioning the .ini file. It is an implementation detail to the
/_config web API.)
That is sufficient to query couch with the _admin role. If you GET
/_session, you see this:
{ ok: true,
userCtx:
{ name: '<whatever>',
roles: [ '_admin'] },
info:
{ authentication_db: '_users',
authentication_handlers: [ 'oauth', 'cookie', 'default' ],
authenticated: 'default' } }
You might ask: why not just have normal user accounts with "_admin" in
the roles. I once asked Chris that question, and he said just in case
something was deeply broken, you can always log in as the admin. What
a great example of evolutionary homology! (Homology is bat wings and
bird wings; fish tails and whale tails). Any Unix sysadmin will tell
you to keep a plain root user in /etc/password, for when your
NIS/LDAP/Kerberos fails.
Problem1: You can't grant additional roles to that user. You can't
give them a couch.app.profile.
Solution 1: Couch (actually this is 100% implemented in Futon if I
recall) creates a corresponding document in _users, to store normal
user stuff
Problem 2: What if the password and salt get out of sync with that in
the config? (Similarly, what if somebody tries to crack your admin
password?)
Solution 2: The document for the admin user omits the password_sha and
salt fields. They cannot go out of sync with the config, and they
cannot be seen by unprivileged users.
Side note: Just like Unix and Windows and everything else, we should
avoid using the admin account whenever possible. You might make an
operator error in Futon (e.g. click "delete database" instead of
"compact database"); and you are also vulnerable to XSS attacks. If
somebody can get javascript into a couchapp you use, they can query
that couch with your _admin cookie.
P.S. Speaking of homologies, it is time CouchDB adopted something like
password shadowing. I wish _users was generally inaccessible to
unprivileged users. You can do this today in the _security object, and
it works just fine; but users can't create or update their accounts.
The Ocasta Facebook plugin, and the BrowserID plugin complement this
with account autovivification. My inbox database patch could help too,
but it's still an incomplete solution. The point is, Couch, just like
Unix, can only go so far with a the comprehensive accounts database
flapping in the breeze.
--
Iris Couch
Re: Conflicting password-storage info on the wiki
Posted by Jens Alfke <je...@couchbase.com>.
On Nov 10, 2011, at 2:02 PM, Adam Kocoloski wrote:
> Heh. No, they're still stored out in the open for anyone to see. Only the server admin passwords are stored in the .ini file. Did you try creating a normal user? As far as I know that documentation is still accurate.
Aha, I’ve only got a single admin account on my server, that explains it.
I can create a normal user by just doing a PUT to _users, but can I create an admin account that way too? Or do I have to modify the config file to do that?
—Jens
Re: Conflicting password-storage info on the wiki
Posted by Jay Zamboni <jz...@vretina.com>.
I am using this couchdb jquery plugin (
http://bradley-holt.com/2011/07/couchdb-jquery-plugin-reference/) to create
user accounts. When creating users this way the information shows up in
_users, not the .ini file.
var userDoc = { _id: "org.couchdb.user:bob", name: "bob" };
$.couch.signup(userDoc, "supersecurepassword", { success:
function(data) {console.log(data); }, error:
function(status) { console.log(status); } });
On Thu, Nov 10, 2011 at 3:02 PM, Adam Kocoloski <ko...@apache.org> wrote:
> On Nov 10, 2011, at 5:00 PM, Jens Alfke wrote:
>
> > According to the wiki[1], the documents in the _users database store
> hashed passwords in “password_sha” and “salt” attributes. But when I look
> at my actual running server, _users documents don’t have those fields in
> them, just “name”, “type” and “roles”. Instead, the hashed password seems
> to live in an [admin] section of the local .ini file, as referred to
> elsewhere in the wiki[2].
> >
> > I’m assuming the “Security Features Overview” page [1] is out of date,
> and the hashed passwords were moved out of the database to make them safer
> from attack?
>
> Heh. No, they're still stored out in the open for anyone to see. Only
> the server admin passwords are stored in the .ini file. Did you try
> creating a normal user? As far as I know that documentation is still
> accurate.
>
> Adam
>
> > If so, what’s the best procedure for adding user accounts
> programmatically? Post to _config first to set up the password, then add
> the user document to _users?
> >
> > —Jens
> >
> > [1]
> http://wiki.apache.org/couchdb/Security_Features_Overview#Authentication_database
> > [2] http://wiki.apache.org/couchdb/Setting_up_an_Admin_account
>
>
Re: Conflicting password-storage info on the wiki
Posted by Adam Kocoloski <ko...@apache.org>.
On Nov 10, 2011, at 5:00 PM, Jens Alfke wrote:
> According to the wiki[1], the documents in the _users database store hashed passwords in “password_sha” and “salt” attributes. But when I look at my actual running server, _users documents don’t have those fields in them, just “name”, “type” and “roles”. Instead, the hashed password seems to live in an [admin] section of the local .ini file, as referred to elsewhere in the wiki[2].
>
> I’m assuming the “Security Features Overview” page [1] is out of date, and the hashed passwords were moved out of the database to make them safer from attack?
Heh. No, they're still stored out in the open for anyone to see. Only the server admin passwords are stored in the .ini file. Did you try creating a normal user? As far as I know that documentation is still accurate.
Adam
> If so, what’s the best procedure for adding user accounts programmatically? Post to _config first to set up the password, then add the user document to _users?
>
> —Jens
>
> [1] http://wiki.apache.org/couchdb/Security_Features_Overview#Authentication_database
> [2] http://wiki.apache.org/couchdb/Setting_up_an_Admin_account