Authentication with salted password

 

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?

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.

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.

  • 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).
  • 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.

    链接地址: http://www.djcxy.com/p/21586.html

    上一篇: GET或POST比另一个更安全吗？

    下一篇: 用腌制密码进行认证