1

I'm using scrypt to generate strong hashes of the password of the user. I want to log the user in, but don't want to send the password in plaintext over the wire, how do I check if the password is correct (without a roundtrip), since it is salted?

I'm having a client / server scenario. The client is an application on a desktop computer (not a website, nor http server).

How can I achieve this? I came only this far: I'm generating the the salt + hash on the client, form a mcf out of it and send it to my server. Save the mcf to the database. I haven't send the password, just the hash which is practically useless (since scrypt should be quite strong, and would require a few million years to reverse it). How can I now log the user into my service, without sending the plaintext password to the server to compare it? I can't rehash it, since it would result in a different hash due to a different salt? I would need to send the salt to the client, hash the password, send the hash to the server, compare it, and send some authentication token back.

How can I achieve this? Is an authentication token actually secure? It can be simply used to impersonate anyone, I guess?

Leandros
  • 16,805
  • 9
  • 69
  • 108

2 Answers2

2

don't want to send the password in plaintext over the wire,

Good idea, but if the connection is not encrypted (something like SSL/TLS), then whatever you send is plaintext. If you hash a password client-side, and send it over the network, then THAT is the password. Some would say that there is no benefit here, but it does prevent the user from exposing their actual password, which they probably re-use on other sites. (read more here)

Ideally you would use something like SSL/TLS to encrypt the connection. I guess if that wasn't possible, using asymmetric encryption with certificates on the message itself that you are sending would be an ok way of re-inventing the wheel, but I am hesitant to recommend that without having a security person look over it. It's very easy to screw up, and the rule is never roll your own crypto scheme.

If you can't verify/invalidate/update the public key, then it is not a good scheme.

I would need to send the salt to the client, hash the password, send the hash to the server, compare it, and send some authentication token back

The salt isn't supposed to be super secret, but it's not great to just give it away like that, especially to unauthenticated users. The authentication token, hash, salt, etc can all be intercepted if the connection is not encrypted. Even if they couldn't, you didn't solve the problem of users creating accounts through this method (maybe you don't need to, but it is worth mentioning).

You have to use asymmetric encryption where only the server can decrypt the data.

Community
  • 1
  • 1
Gray
  • 7,050
  • 2
  • 29
  • 52
  • 1
    `then THAT is the password`. doh. You're correct. How are common applications are handling mitm attacks? I'm obviously doing any communication over SSL/TLS. I also thought about making use of HMAC to verify all requests with some hash, but I would have to send it atleast once anyway, which makes it useless alltogether. – Leandros Sep 30 '15 at 20:14
  • 2
    "I'm obviously doing any communication over SSL/TLS." Then you are doing it right, bro. Under the hood, TLS uses an HMAC to ensure that modification of the message would result in an error. Your setup sounds secure then - since the password is not actually in plaintext. With TLS, the attacker should not be able to do a MitM attack on you - it would require screwing with your trusted CAs on the local machine. – Gray Sep 30 '15 at 20:19
  • I was discussing the issue with a friend of mine, SSL is basically using public / private key encryption, right? (something along the lines of [this](https://www.comodo.com/resources/small-business/digital-certificates2.php)). Which is the same as your mentioned asymetric encryption? – Leandros Sep 30 '15 at 21:14
  • @Leandros you're correct. That's exactly what SSL is. I was trying to think of what I'd do if someone told me I couldn't use it with that comment I made. It's a moot point now that we know your connection is secure. – Gray Sep 30 '15 at 21:15
1

There is no short answer to your question, because there are so many pitfalls that can happen if you do it wrong. But as Gray says, you do need TLS protection.

I have two sources that give you detailed explanations on the right way to do this if you want to do client side scrypt processing.

  1. Method to Protect Passwords in Databases for Web Applications. If you do not want to understand all the rationale, just jump to section 4 to see the implementation (where PPF = your scrypt).
  2. Client-Plus-Server Password Hashing as a Potential Way to Improve Security Against Brute Force Attacks without Overloading the Server.

They are slightly different solutions but based upon the same ideas, and either should be good enough for you.

TheGreatContini
  • 6,429
  • 2
  • 27
  • 37