Sending extra credentials to proxy

[Alan McKean]

I'm working on setting up a proxy server in Node.js that accepts the incoming replication request and proxies it to the target CouchDB database. I have two tiers of authentication. After getting the incoming request in the Node.js proxy server, I want to authenticate the user by comparing their login passKey with what I have on record. Is there a way to configure the replication pull and push requests to send that first-tier passKey in the body? The second tier of authentication is in the CouchDB username and password that CouchDB handles. I suppose I could hack it by concatenating the two usernames and passwords and parsing them in the Node.js server, but I was hoping for a better way.

[Jens Alfke]

On Mar 6, 2014, at 9:58 AM, Alan McKean <alanm...@me.com> wrote:

After getting the incoming request in the Node.js proxy server, I want to authenticate the user by comparing their login passKey with what I have on record. Is there a way to configure the replication pull and push requests to send that first-tier passKey in the body?

What’s a passKey?

In general the answer is no, there’s no way to customize the bodies of the requests sent by the replicator. (There are a bunch of different REST calls anyway, with different data schema.) You can add custom HTTP headers, though.

Maybe you can explain why you need a second layer of authentication on top of what CouchDB provides? And why the HTTP Basic, OAuth, Facebook and Persona mechanisms we already support aren’t meeting your needs? ;-)

—Jens

[Alan McKean]

I have registrations in a registration db in CouchDB. During registration, the user creates a 'login' password and a hash of that password (the passKey) gets stored in the registration db. When a request comes in, it has the user's passKey in it. I compare that user's passKey to the registration passKey before passing the request along to CouchDB on my db server. The CouchDB request has the db's username/password in it, so there is a second authentication there.

The reason I have this extra layer of authentication in Node.js and am using a proxy server at all has to do with the recommendations that I have from my HIPAA security consultant. He said that although HIPAA does not require it, opening a port to CouchDB on my db server would violate a 'best practice' in HIPAA architecture. If I need to, I can eliminate the extra authentication in the CouchDB requests because they have already authenticated with the passKey at login. But the extra layer of authentication makes me feel more secure.

[Jens Alfke]

On Mar 6, 2014, at 10:39 AM, Alan McKean <alanm...@me.com> wrote:

I have registrations in a registration db in CouchDB. During registration, the user creates a 'login' password and a hash of that password (the passKey) gets stored in the registration db. When a request comes in, it has the user's passKey in it. I compare that user's passKey to the registration passKey before passing the request along to CouchDB on my db server.

If I understand correctly, that’s not secure. You’ve made the passKey a primary credential that you’re storing directly on your server. If an attacker stole the registration db, they could successfully authenticate by sending requests with passKeys in them. It’s exactly as if you were storing passwords in plain-text.

The standard way to do password hashing is for the client to send the password, which the server then hashes and compares to its stored hash. That way the credential stored on the server can’t be used to log in. Also, you should (a) prepend a constant ‘salt’ string to the password before hashing it, and (b) use a slow hash algorithm like bcrypt, to prevent attackers from brute-forcing millions of passwords. Also, it goes without saying that you should do this over SSL because the client is sending a password.

He said that although HIPAA does not require it, opening a port to CouchDB on my db server would violate a 'best practice' in HIPAA architecture. 

Along those lines, what are you doing to prevent users from reading other users’ documents from the CouchDB database?

—Jens

[Alan McKean]

Good points. I'll fix the passKey issue.

A given user can only read from their own db because each user has a unique username/password combo in _users. The user's db username/password is sent with each db request. All communications are over https.

On Thursday, March 6, 2014 9:58:49 AM UTC-8, Alan McKean wrote:

[Jens Alfke]

On Mar 6, 2014, at 11:24 AM, Alan McKean <alanm...@me.com> wrote:

A given user can only read from their own db because each user has a unique username/password combo in _users. The user's db username/password is sent with each db request. All communications are over https.

Oh, you’re using the database-per-user approach. That’ll do, as long as you don’t need to share data between users; then it gets messy :)

—Jens