hashing is a one way method, if a user lost his password he will never be able to get that password from the server, so why don't we store passwords in a database using encryption instead of hashing?
3 Answers
Because if a user can get their password out of the database, then so can:
- The system/database administrator.
- The school/employer/government who's proxying the user's Internet access.
- The hacker who pwned the WiFi at the coffee shop.
- The hacker who pwned the user's e-mail account.
- The hacker who pwned the server.
In some of these cases, ease of access is dependent upon whether or not the system is vulnerable to other exploits. In others, the damage can be exacerbated or reduced depending on the user's password hygiene.
However, all cases represent scenarios where hashing would mostly - if not completely - block people who shouldn't have access to other people's passwords. Encryption cannot help here.
It's also worth noting that a user does not ever, for the purposes intended by any website, need to get their actual login credentials from the system. In the case that a user forgets their password, the system should provide a mechanism by which they can securely reset or change it to a new, known value.
Will switching to password hashing and implementing a reset (instead of recovery) process absolutely prevent an attacker from accessing a user's account in all the scenarios above? No. But it certainly raises the bar, and ensures that the damage for the user is isolated to just that one account - not every account the user used the same password on.
When your user logs in, you will have to know if the password is correct.
Hashing a password means you don't need to know the password, just the hash. As hashing is one-way, if someone leaks your database, they will only have the hashes and will have to bruteforce every one to get the passwords. Using salts, bcrypt and a lot of rounds makes very, very difficult to crack all the passwords.
Encryption is reversible. Your user submit the password, your site decrypts the stored value, and compares. The problem is that your site have the decryption key. If someone hacks your site, he will get the key, and decrypt every single one of the passwords, effortlessly. Not nice.
It's almost as insecure as keeping the password on cleartext.
Main advantages of hashing versus encryption:
- the administrator of the website doesn't know your password (see Iszi 's answer);
- if the database is breached, it is easier for the attacker to break a single encryption key than to obtain the passwords from N (10^4, 10^6,...) properly salted hashes (see ThoriumBR's answer);
- you don't actually need to get that password if you forget it. It is enough to have a proper password reset mechanism. The only reason why you would like to get the original password, instead of resetting it, is if you use the same password for a lot of websites (and you don't want to go through the hassle of resetting the password everywhere), but this is really bad, even if the password is very strong.
never be able to get that password from the server
working as intended! If the system is good enough for authentication but cant be used to compromise other authentication systems (user uses password on more than one server ... something that shouldn't happen but does) then not only is there no need for it to be reversible but it is actually safer for both the user and the service holding it to not have it be reversible. If server gets hacked the service can admit as much and say that passwords where hashed ... and are non reversible.