Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

CouchDB Authentication

I've read a lot of things about authentication in CouchDB, especially regarding the Cookie Authentication. I'm still making some tests and all seems working well, for instance with this command :

curl -vX POST $HOST/_session -H 'application/x-www-form-urlencoded' -d 'name=foo&password=bar'

I get a Cookie that I can use. But my point is, anytime I see think kind of sample on the Web, the username and password are always sent in plain text.

I'm really new to security but what's the interest of the Cookie Auth method if I first have to send my credentials in clear ?

Is there a way to send at least the password hashed ? With something like that IDK :

curl -vX POST $HOST/_session -H 'application/x-www-form-urlencoded' -d 'name=foo&hashed_password=hashed_bar'

Cheers

Arnaud

like image 430
Arnaud Avatar asked Feb 23 '11 14:02

Arnaud


3 Answers

If you send your password hashed than all the attacker needs to know is your hashed password so it wouldn't solve the problem of sending your password in cleartext - now you would have a problem of sending your hash in cleartext.

Also remember that even if that solved the problem you would still be sending your cookie in cleartext being vulnerable to session hijacking.

(There's also the HTTP digest access authentication but not without its own problems - but CouchDB didn't support it last time I checked anyway.)

What you should do is to always use HTTPS for any authenticated CouchDB access with any network involved, except maybe the 127.0.0.0 network.

(And yes, pretty much all of the examples on the web and in books show using basic or cookie authentication over HTTP which in my opinion is a disaster waiting to happen.)

like image 193
Zed Avatar answered Oct 09 '22 09:10

Zed


Using Https is the right answer.

I'll add a clarification on the importance to compute a hash on the server side. The hash is a one way function transforming the input into the key value stored in the server. If someone hacks the server and gets the hashed input (key value) he won't be able to deduce the input value from it to impersonate you.

If you compute the key value on the client side and no one way tranformation is performed on the server, it is equivalent to store passwords in clear text. Someone who managed to get a copy of the key value stored on the server can easily impersonate you by simply sending the key value.

Thus applying on the server side a cryptographically secure one way function (i.e.sha256) with a salt/random seed on the submitted password is required to secure the password database.

Obfuscating the sent password by hashing it, in addition to hashing it on the server side, won't help mutch if the sent hashed value is always the same. However spying data sent through an SSL connection is not trivial.

There is however a significant benefit to hashing password on the client side. A brute force attack on the server by trying to guess the password using a common password dictionary would become hopeless because the hashing on the client side randomized the password.

We may add some salt to the hash to protect against use of hashed password dictionary. When the user typed his user id, ask for the user specific salt value to the server. Then use the returned salt or hash seed value to generate the hashed password on the client side.

Brute force password guessing maybe hindered on the server side by increasing the time interval between retries. But this generally works for one specific connection. The attacker may reconnect after every two attempts. It is then required to keep track of ip addresses to recognize such type of attacks.

like image 39
chmike Avatar answered Oct 09 '22 08:10

chmike


As of version 1.1, CouchDB, supports API access via HTTPS. Instead of using an HTTPS proxy, you can use HTTPS directly, protecting passwords transmitted over the wire. See the Feature Guide for 1.1.

like image 2
Barry Wark Avatar answered Oct 09 '22 09:10

Barry Wark