couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@iriscouch.com>
Subject Re: Conflicting password-storage info on the wiki
Date Fri, 11 Nov 2011 01:14:49 GMT
All this s/homology/analogy/

How humiliating!

On Fri, Nov 11, 2011 at 8:00 AM, Jason Smith <jhs@iriscouch.com> wrote:
> On Fri, Nov 11, 2011 at 5:41 AM, Jens Alfke <jens@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

Mime
View raw message