2 ms·

Let's say a company does implement client side hashing. Now the server just needs the hash to log you in. Isn't the hash now basically the password? Now if the

by httpz 8y ago

Let's say a company does implement client side hashing. Now the server just needs the hash to log you in. Isn't the hash now basically the password? Now if the hash leaks or gets logged, a malicious user can still login to the company service using that hash. Only difference is, since it's not a plaintext password, with proper salting the user is somewhat protected from having their other services with similar password hacked.

ndiscussion 8y ago
FB could also rotate the hash any time, with a short overlap period to allow for already-loaded pages, to eliminate this issue.
gylterud 8y ago
Consider this approach: Let H be a hashing function and p be the users password. In the database you store a nounce n, and H(H(p⊕n)). When authenticating the server sends n, and client responds with x=H(p⊕n). Now server can compute H(x) and compare with the stored value to authenticate the client. Finally, after it has been authenticated, the client generates a new nounce n', and sends H(H(p⊕n')) and n' to the server, which is stored in the database for the next log in. Replace the outer H with a proper key derivation function for extra credits. This avoids sending any secret value over to the server, so no server side logging will cause a problem.
jeltz 8y ago
SCRAM has solved this and with it the server can verify that the client has the plain text password while only storing the hashed password a d without exchanging a plain text password.
httpz 8y ago
After reading the comments I have an idea. I'm sure someone thought of it already though. If the password is p and the hash function is H(), server stores the hashed password H(p). When the login screen loads, server sends the server time so with reasonably fast internet, the client can estimate the server time. Let's call the estimated current server time t. On login, client sends H(H(p)+t) with t. Now the server can compute H(H(p)+t) with the t from the client and verify if the hash match and also check if t is within few seconds of the current server time. This way if any data that goes over the network leaks for gets logged, it'll only be valid for few seconds. Also salting before hashing should go somewhere in there but it'll make it a bit more complicated.

by httpz 8y ago

ndiscussion 8y ago

FB could also rotate the hash any time, with a short overlap period to allow for already-loaded pages, to eliminate this issue.

gylterud 8y ago

Consider this approach: Let H be a hashing function and p be the users password. In the database you store a nounce n, and H(H(p⊕n)). When authenticating the server sends n, and client responds with x=H(p⊕n). Now server can compute H(x) and compare with the stored value to authenticate the client. Finally, after it has been authenticated, the client generates a new nounce n', and sends H(H(p⊕n')) and n' to the server, which is stored in the database for the next log in. Replace the outer H with a proper key derivation function for extra credits. This avoids sending any secret value over to the server, so no server side logging will cause a problem.

jeltz 8y ago

SCRAM has solved this and with it the server can verify that the client has the plain text password while only storing the hashed password a d without exchanging a plain text password.

httpz 8y ago

After reading the comments I have an idea. I'm sure someone thought of it already though. If the password is p and the hash function is H(), server stores the hashed password H(p). When the login screen loads, server sends the server time so with reasonably fast internet, the client can estimate the server time. Let's call the estimated current server time t. On login, client sends H(H(p)+t) with t. Now the server can compute H(H(p)+t) with the t from the client and verify if the hash match and also check if t is within few seconds of the current server time. This way if any data that goes over the network leaks for gets logged, it'll only be valid for few seconds. Also salting before hashing should go somewhere in there but it'll make it a bit more complicated.