If the password is hashed and then sent to the server where the hash is compared to the stored hash, this basically means that if someone had that hash they can still log in by sending the hash in the request, the password is just useless at this point.
I am talking with respect to Bitwarden. How does hashing a password make it more "secure"?
If the password is hashed [locally] and then sent to the server where the hash is compared to the stored hash ... I am talking with respect to bitwarden
This is not how it is done. From Bitwarden help:
Bitwarden salts and hashes your master password with your email address locally, before transmission to our servers. Once a Bitwarden server receives the hashed password, it is salted again with a cryptographically secure random value, hashed again, and stored in our database.
So basically the locally hashed password is treated as the server visible secret and this is properly protected with server side hashing.
The point of local hashing is that the password that the user can remember is never transmitted, i.e. it is an additional security measure. While it is true that the resulting hash would be usable by an attacker instead of the original password, it is much harder to guess the long and kind of random hash than the way more weak password. And brute forcing this original user password is also made harder due to a deliberately slow hash function. What Bitwarden does here to harden a weak password is also known as Key stretching.
I don't know much about Bitwarden, so this is a general answer.
Taking from Steffen Ulrich's answer though, let's analyse this flow:
I'm omitting parts like salting and the choice of the hash algorithm, because all that they do is just make bruteforcing (aka guessing all possible passwords to find one that matches a hash) harder. We'll assume that the hashing algorithm is good enough that bruteforcing is infeasible.
So what's the reason for hashing at points (2) and (4)?
The hashing at (2) is done to remove the actual password from sight. People often do use the same password on multiple websites, so we want to do all that is possible to prevent hackers from seeing them. Even if our website gets compromised, at least we can protect our user's accounts on other websites. By hashing it already at (2) we ensure that no matter what the hackers might have compromised further down the line, they will NEVER get to see to the actual password.
Of course, if they have compromised your computer and installed a keylogger, then you're doomed. 100% security is impossible. But other parts of the system can be protected. And for hackers it is more efficient to go after servers, which are central points where 1000's of users connect to, than to try and hack 1000's of user computers (although the latter can be somewhat done with viruses and phishing).
Anyways, back to our scheme. So the point (2) is clear - but then why (4)? Precisely because of what you observed - that if someone gets their hands on the hash from (2), then even if they don't see the actual password, they can at least get access to THIS system. The hashing at (4) makes that harder, because it removes one place where the hashes from (2) could be found en masse - the database which stores them. Servers can and do get hacked, and every so often a hacker finds themselves with access to some database. Maybe it is the live production database, maybe it is a backup copy, who knows. The point is - if we do step (4), then the hashes from (2) won't be there. Only hashes-of-hashes. And you can't use those to log on to the system.
Of course, if you have access to the database, then maybe you don't care about knowing the hash from (2) anymore... Or maybe there is still something that cannot be accessed without knowing it. For example, you could encrypt some data by using the hash from (2) as a key.
this basically means that if someone had that hash they can still log in by sending the hash in the request,
No this is a misunderstanding because you're forgetting that the program or app process is the same regardless of the input. This means if you send a hash as input it will be hashed again creating a completely different value. You would have to separately compromise the application or server in order to do what you are imagining.
On a deeper level it also helps programmatically in making the data input uniform in size and things like that which is why computers do it all the time.
The point is to not be storing or transmitting passwords in plain text. This is basically it. Everything else is all about making it hard to derive that text or other text that will achieve the same end, otherwise we would just use CRC-16 an be done with it.
Where this falls over is that storing a hash digest where people have access to both the digest and the hash algorithm becomes a risk.
So generally it is encrypted at rest after multiple rounds of hashing and salting, and there is minimal access to the encrypted data.
Frankly the encryption and vaulting is more important than salting and hashing. Given 30 million hashes it is trivial to group and sort the duplicates, and we pretty much know what the top 50 will be.
But really - not plain text. That is all. Not to prevent index hotspots or file splitting, but plain text. In the days of FTP an Telnet and Kermit we did not have SSH, or SSL, or IPsec.
I think the other answers do not properly address your question about the risk of an attacker re-using the hash that the client sends. Therefore:
While the hashing prevents the server from ever knowing the plain password, your point is absolutely valid: it does not prevent a malicious re-use of the hash. If the client-side generated hash is used again, that is referred to as a replay attack.
This can be avoided by adding a session token, which is randomly generated by the server and sent to the client with the login request. The session token can be used as a salt to hash or encrypt the transferred value. (In this case, it would be encrypt, because it needs to be reversible by the server.) See Prevention and countermeasures in the Wikipedia article for details.
If an attacker then gets hold of the transferred value, it is useless, because if they open a a login request, the server will generate another session token.
For clarification: this would have to be an additional measure on top of rather than instead of the existing hashing.
Does Bitwarden use a session token?
Searching the Bitwarden online documentation, I wasn't able to find out if Bitwarden uses this technique. Instead, I found this reddit thread which actually supports your concerns.
Yet, note also that Bitwarden offers two-factor authentication (2FA), which mitigates the risk of a replay attack significantly.
Based on the elaboration in the answer by Steffan that both client and server do some hashing, there are a few notable security advantages to doing it this way compared with just sending the password.
