On Mar 6, 2014, at 10:39 AM, Alan McKean <[email protected]> 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
smime.p7s
Description: S/MIME cryptographic signature
