passwords

[svilen]

g'day

i am trying to set a user with a password that is not just alphanumeric.
e.g. "b:@" (or if uri-encoded, b%3A%40)

but the result of getting the /_users/ doc is always 401-unauthorized.

if i login in Futon, it seems to work.
when i compute the pasword_sha myself and compare to whats in user/doc,
it matches.

but http via basic authentication won't let me in.
e.g.
curl -vX GET
http://auser:b%3A%40@server:5984/_users/org.couchdb.user%3Aauser

(seems the subject is very tricky and rarely paid attention to in
various http libraries i looked recently. Everyone just lumps the
usr+":"+psw and uri-encoding/decoding is left out..)

any idea of what can be the problem?
what is Futon using so i can check the source?

ciao
svilen

[svilen]

so there is an issue about it
https://issues.apache.org/jira/browse/COUCHDB-969

which says "resolved", but looking at 1.2.0 sources - couch_httpd_auth/
basic_name_pw, i don't see any special case (or test). (although i cannot read Erlang well)

i tested with passwords like "//" and "@@", seems to work. So it's only
':' that is the trouble as in the issue above.

ciao
svilen

[Robert Newson]

Hm, I made an admin 'foo' with password 'foo:bar' just fine (on master
branch, but this hasn't changed since those fixes I think).
B.

[svilen]

i just tested these:
'h:h' - works
':h' - fails
'h:' - fails

seems ':' at any end breaks it.

[Dave Cottlehuber]

On 23 April 2013 13:15, svilen <a...@svilendobrev.com> wrote:
> g'day
>
> i am trying to set a user with a password that is not just alphanumeric.
> e.g. "b:@" (or if uri-encoded, b%3A%40)
>
> but the result of getting the /_users/ doc is always 401-unauthorized.
>
> if i login in Futon, it seems to work.
> when i compute the pasword_sha myself and compare to whats in user/doc,
> it matches.
>
> but http via basic authentication won't let me in.
> e.g.
> curl -vX GET
> http://auser:b%3A%40@server:5984/_users/org.couchdb.user%3Aauser
>
> (seems the subject is very tricky and rarely paid attention to in
> various http libraries i looked recently. Everyone just lumps the
> usr+":"+psw and uri-encoding/decoding is left out..)

Hi Svilen,

From curl, you can:

curl -vX GET $COUCH -u tricky:p@sswd

and leaving off the password field allows you to enter it manually or
even echo ':p@sswd' | curl …

or if you're POSTing I think you can also use this:
http://curl.haxx.se/docs/manpage.html#--data-urlencode

curl -d name=john --data-urlencode passwd=@31&3*J https://www.mysite.com

Anyway AFAICT there's a bug in CouchDB if the password starts with a `:`

$COUCH=http://admin:pwd@localhost:5984

curl -HContent-Type:application/json \
-vXPUT $COUCH/_users/org.couchdb.user:mrtricky \
--data-binary '{"_id": "org.couchdb.user:mrtricky","name":
"mrtricky","roles": [],"type": "user","password": ":pwd"}'

I would expect that I can subsequently use either curl or httpie.org,
neither of them succeed with -u mrtricky::pwd or -u mrtricky & getting
password from terminal.

A+
Dave

[svilen]

yeah, it fails if password starts or ends (or equals) ':'

probably because of that same function - basic_name_pw

funny how i manage to step on these..

so i'll have to forbid having ':' in userid, and in password... as
workaround.

ciao
svilen

[Robert Newson]

Ah, that's a great distinction, rings a bell!

[Robert Newson]

I believe the fix for this is 5d4ef930 which is on master (which will
be 1.4) only.

specifically;

- [Name, Pass] = re:split(NamePass, ":", [{return, list}]),
+ [Name, Pass] = re:split(NamePass, ":", [{return, list}, {parts, 2}]),

B.

[Noah Slater]

Can we put this into one or more of the bugfixes branches?

--
NS

[Robert Newson]

good thought.

[Noah Slater]

Any other bugs while we're at it. I'll be sending out a formal request
tonight for people to do merges. But may as well mention it now.

--
NS

[Robert Newson]

Probably, I only have time today to test and backport this issue,
given that I wrote the fix for it.

eta 10 mins.

[svilen]

the one of user unable to DELETE itself, from the other day..
don't know if it has been fixed or not.

[Robert Newson]

svilen,

I don't think that's considered a bug, though. Admins can delete
users, users can't delete themselves. We can certainly debate that,
but I think our position is that this is intentional.

I'm also backporting the configure.ac fix as it makes it hard to run my tests.

B.

[Mike West]

+1 as a security feature, not a bug.

Mike

[Robert Newson]

All pushed now, I even added a test (to users_db.js, it was closest).

[svilen]

ah.
i'll be updating the userdoc with _deleted=true then, it does all the
job including showing as delete in _changes. well, yet another
workaround.

ciao
svilen

[Robert Newson]

_deleted:true is exactly the same as DELETE to couchdb. It's curious
we block one and not the other, so I guess that's just a mistake. The
injected ddoc specifically allows a user to delete their own document.

if (newDoc._deleted === true) {
// allow deletes by admins and matching users
// without checking the other fields
if ((userCtx.roles.indexOf('_admin') !== -1) ||
(userCtx.name == oldDoc.name)) {
return;
} else {
throw({forbidden: 'Only admins may delete other user docs.'});
}
}


Also this is no longer on topic. :D

B.

[Robert Newson]

fyi: I had no trouble deleting my own user document;

➜ ~ curl 'foo:bar@localhost:5984/_users/org.couchdb.user:foo?rev=1-f77e70173079dbbf2f5f2ea1075ca5a7'
-XDELETE
{"ok":true,"id":"org.couchdb.user:foo","rev":"2-efdf988662f5577cf4ce6213bcf5f832"}

➜ ~ curl 'admin:admin@localhost:5984/_users/org.couchdb.user:foo'
{"error":"not_found","reason":"deleted"}


B.