GET PLAIN TEXT FROM KNOWING HASH AND SALT PASSWORD
Since H = hash(plain_password + salt) now behaves a little bit like a new plaintext (see the 2nd answer of Zero Knowledge Password Proof: why is hashing the password on the client side not a ZKP?), then the sever can store (username, salt, server_salt, hash(H + server_salt)) in the database, instead of (username, salt, H). So this means that the server is disclosing salt to anyone trying to log in with a given username.īenefit: the server stores a salted+hashed password (which is standard) but also the server has never, ever, seen the plaintext password even once (so if the server is compromised, the risk is limited) Subsequent logins: the server has to send salt back to any client who tries to login with a given username, so that the client can hash with the same salt. Then the plaintext password never reaches the server. Signup: client generates a random salt, and sends the tuple (username, salt, hash(plain_password + salt)) via a POST request. Is the following alternative more secure than sending plaintext password over HTTPS? Is this login method still industry standard? Many popular websites (Reddit, HN, etc.) still send the password in plaintext in the (SSL-secured) POST request (see screenshot below).
Note: I've already read Is it ok to send plain-text password over HTTPS? and https security - should password be hashed server-side or client-side?, but here it's about a specific replacement method (see below).Īfter reading an article about a new authentication method on the Cloudflare blog, I looked at the POST requests that are sent while authenticating with "Developer Tools > Network".
0 kommentar(er)
