3 ms·
All the answers I see on stack say there is no gain to do hash or encrypt prior to sending. I'm not sure I can agree with this. Let's say you hash a password an
by sebringj 8y ago
All the answers I see on stack say there is no gain to do hash or encrypt prior to sending. I'm not sure I can agree with this. Let's say you hash a password and some attacker gains this. They can now log into that website BUT NOT everyone else for your username if you happen to use the same password. Jeez am I wrong here?
- johnnyRose 8y agoI have looked into this in the past and came to the same conclusion. Essentially, the "password" sent to the website is the client-side salted/hashed version of the user's actual password. The server could then salt/hash the "password" another time before storing it. This could result in the same issue if the "password" is logged, but it protects the user's true password from being discovered. Maybe a security expert can weight in on this, because I don't understand why this wouldn't be the standard.
- lixtra 8y agoIdeally the server doesn’t need to remember the salt it sent to the client, so it should be signed together with a timestamp to avoid reuse. While you’re at it you can also add some hash puzzle to be solved by the client increasing difficulty with failed logins.