Originally posted by pauldee
View Post
That's why you buy a product to do it for, specifically one with role based access control and auditing.
Since the question makes no mention of salt/pepper, we'll stick to plain hashing of password (a terrible idea by the way). I'm assuming we're doing server-side hashing, as client-side hashing is also a terrible idea.
Let's denote the following:
P: the password
H(P): the hashed password
You enter P in the login form of the website. The backend computes H(P) by running it N (let's say 1000) times through sha-256 (just to pick one). The backend looks up your user entry in its database and checks whether the computed H(P) matches the H(P) stored as your password. If it does: congratulations, you're you. Otherwise, "wrong password".
Now, an attacker got his grubby little hands on a dump of the database's user entries, including username and the H(P) for each user. However, the attacker does not have direct access to the database.
The attacker goes to the website, types in your username and H(P) as your password. The backend computes the hash of your password: H(H(P)). But lo and behold, H(H(P))≠H(P) because one is hashed 2∗N times, the other N times.
All that's left is for the attacker to try to get the original password out of the dump of hashes. But this is a story for another day.
PS: if you do want to do client-side hashing, you still need to do server-side hashing. The stored value in the database would be Hserver(Hclient(P)). Never store client-side hashes, that's just as bad as storing the password.
Let's denote the following:
P: the password
H(P): the hashed password
You enter P in the login form of the website. The backend computes H(P) by running it N (let's say 1000) times through sha-256 (just to pick one). The backend looks up your user entry in its database and checks whether the computed H(P) matches the H(P) stored as your password. If it does: congratulations, you're you. Otherwise, "wrong password".
Now, an attacker got his grubby little hands on a dump of the database's user entries, including username and the H(P) for each user. However, the attacker does not have direct access to the database.
The attacker goes to the website, types in your username and H(P) as your password. The backend computes the hash of your password: H(H(P)). But lo and behold, H(H(P))≠H(P) because one is hashed 2∗N times, the other N times.
All that's left is for the attacker to try to get the original password out of the dump of hashes. But this is a story for another day.
PS: if you do want to do client-side hashing, you still need to do server-side hashing. The stored value in the database would be Hserver(Hclient(P)). Never store client-side hashes, that's just as bad as storing the password.
Comment