Consider the following interaction:
A user stores their username and password on a web server. For the sake of security, the server records a hash of the password plus some unique salt.
While the user is using a client application, it makes a request to the server submitting their username and a hash of the password plus some other unique salt.
So you have the following information on the server and need to know whether or not the request is authentic:
- The server's salt
- The server's hashed password
- The client's salt
- The client's hashed password
Again ... client sends: clientSalt
+ MD5(clientSalt + password)
. Server has serverSalt
+ MD5(serverSalt + password)
. I don't want to know the password, I just want to know if the hashes were calculated from the same password.
Without knowing the password that was hashed, is there any way to verify that both hashes are of the same password?
My goal is to allow some form of secure authentication in a client-server environment without ever exchanging the actual password over the wire. This is just one idea I've had, but I don't even know if it's possible.
That would require unhashing the password, which is not possible. If the server receives: salt, md5sum
, it can't see what went into the md5sum.
A challenge-response protocol would work instead. The server should generate a random value nonce
and send it to the client. The client calculates md5(md5(password) | nonce))
and returns it to the server. The server verifies by checking md5(storedpassword | nonce)
.
No, you can't do this.
Once you add a salt into the mix it becomes practically impossible to compare hashes. (To do so would require "un-hashing" those hashes somehow before comparing the "un-hashed" data.)
Challenge-response authentication is probably the way to go, possibly using Kerberos, depending on your tradeoffs. One of the tradeoffs being the possibility for attackers controlling the clients to use compromised hashes to authenticate themselves.
Don't invent your own cryptographic protocols. Use one that is well-known and well tested. If possible, use an existing (vetted) implementation.
My goal is to allow some form of secure authentication in a client-server environment without ever exchanging the actual password over the wire. This is just one idea I've had, but I don't even know if it's possible.
For this, I advise looking into Kerberos: Official Site and Wikipedia
It's impossible. If you don't store password on the server, user must provide it.
OR
If you store password on the server, user can provide hash calculated using requested salt.
You will not be able to verify the hash with this setup. If you don't want someone to see the password go over the wire, SSL is the easier way. If you don't want to use SSL, you could check out SRP. Additionnally: don't use MD5+Salt to store your password, use key strengthening functions like bcrypt or scrypt.
精彩评论