Doesn't hashing passwords server side mean a compromised website could leave passwords vulnerable?

Question

So the traffic is encrypted to a website so the password is safe during transmission and also if the website is hacked then the database only contains hashes.

But couldn't the hacker create a server side script to store the usernames and passwords used to login to the website in a file since they are decrypted and are not already hashed? This wouldn't get every user however it would allow them to view users passwords who try to log onto the site while it is compromised.

Wouldn't it be better to hash passwords at the client side?

Answer 1

The weakness you allude to is real. An important point is that once the server is compromised, the attacker has little incentive to grab passwords that grant access to that server -- he is already in the place. However, human users have the habit of reusing passwords, and that is a big problem, because a reused password means that compromises on one server tend to "propagate", exactly in the way you explain: the attacker grabs password P for user U, and guesses (alas correctly, most of the time) that the same user U will have used the same password on some other servers.

Hashing client-side is a nice idea, but there are details:

• Whatever the client sends to the server, be it the password itself or the hashed password, grants access. It is password-equivalent. If the server stores these hashes "as is" in its database, then it is in the same situation as a server storing plaintext passwords, and that's bad. Thus, the server MUST also do some hashing.

• Client-side hashing occurs only if there is code on the client side that does the hashing. In a Web context, this means JavaScript. Unfortunately, JavaScript is poor at cryptographic implementations; in particular, it is quite slow, so the client-side hashing will not be able to use the many iterations that are usually needed for good password hashing (see this for details). Also, this would not work for clients without JavaScript.

• Still in a Web context, the client-side hashing, if it occurs, is done by JavaScript code sent by the server. If the server has gone under hostile control, then it may send malicious JavaScript that pretends to do the hashing, but does not. The user will be none the wiser. Thus, the root problem is not solved.

Client-side hashing is usually envisioned under the name of "server relief", not to increase security against evil servers, but to allow the server to handle many concurrent users without spending all its CPU on a lot of hashing. JavaScript being what it is, this is not commonly done nowadays.

Answer 2

So there's two separate parts to this.

First, the server getting compromised, and second, sending hashes to the server instead of passwords.

For the first part with the server getting compromised, yes, the attacker could pretty much do whatever they want. If they own the server, they can indeed get the usernames and passwords from the users being passed to the server. This is why servers need to be hardened against attacks and regularly updated so that they offer as little of attack surface as possible.

For the second part, if you have the client pre-compute the hash, then that hash has literally become the password. If an attacker were to have stolen the database of hashes(but hasn't compromised the web server), he doesn't need to find the passwords that turn into those hashes; he can just send the hash to the web server, and it would authenticate since the server would already be expecting a hash as input to compare against its database.

Answer 3

You likely wouldn't be able to prevent simple server-side modification of the code sent to clients to execute if your server is totally owned.

However if this is part of a pre-installed or pre-distributed software package with distinct client and server components (this could include web applications with downloaded components that stay resident on the client OS), client side hashing could be useful in the sense that, while the attacker can likely still use those hashes for authentication to YOUR database (or just reset passwords as mentioned in one of the comments), they no longer have easy access to the plaintext password that would be sent to your server (over SSL) for salted hashing and database storage.

So, if you have a client using the same password in multiple places, so long as the hash isn't trivially reversible, your particular server compromise has no longer disclosed credentials the attacker can use elsewhere. This would be enhanced with random client-side salting (so that you're not ending up with the same hash that the same algorithm would always generate for that plaintext).

Answer 4

I find a lot of people (especially in the PHP realm) misunderstand what hashing does. Here's the methodology

1. User creates account and sends a username/password combo to you (securely over HTTPS I hope)
2. Password is hashed on the server (with a random salt) and stored with the username
3. User comes back later and enters their plain text password
4. Server finds the stored hash for the username. With $2y hashes (BCRYPT) the cost and salt are stored in the same string. So using the same cost and salt, the server generates a hash using the user provided password (remember, hashes are one-way by design)
5. With everything being the same, if the generated hash matches the stored hash, we can authenticate the user

Assuming that someone hacks your server your users are better protected because the salt is random for each hash. As such, you would have to brute force each password separately (the core theory behind any type of security is to raise the cost of doing something to the point where someone will not attempt it). SHA1 and MD5, the previously popular hashing systems, were almost always generated without any salt, making them susceptible to not only any weaknesses in the hash itself, but rainbow table attacks (without salt each SHA1 and MD5 is the same for a given string).

There's really no way to do this client side because

• The client is in the hands of the enemy. So you would have to send the client everything they need to generate the hash (most notably the salt) and then have them pass back the hash.
• As mentioned in another answer, at that point their hash becomes the password because that's what they send to you. In other words, even though I might not know what the password is, you're still doing simple string comparison instead of generating a secure hash so I can break in

Answer 5

No, Inspect Element or something similar exists on most browsers, allowing anyone to bypass client-side code. If a hacker got access to the database, they could remove the hashing code using Inspect Element and enter the hashes as passwords, or edit the page to not hash it anyway. How about instead, a script that stops the server if it senses a page has been modified by a hacker?