What is the point of salt and hashing if database

问题:

I just learned the concept of hashing ("Hey! don't forget the salt!") and using salt to make the password secured.

Hashing it is a one way encryption (actually not encryption but hashing) so it cannot be reversed engineered. Salting is prefixing or appending randomly created values to the password before hashing 'coz the problem in hashing (just hashing) is, some genius has provided a hash table of words from the dictionary so that they'll just compare the hash from that dictionary to the user's table from the database to login - W-wait? did I say table from the database? So it means somebody can access the database so we have to use salt? If that so, then why would the hacker recover the password if he already has access to the database? If I were him, I'll just get all the details I want from the database, why would I use the key I've stolen from a house to open the door if I can access the house already through the window?

So, why hash? why salt? I don't understand. Please, somebody help me.

Thanks in advance.

Important Note: I'm not against hashing or salting, I just want to clarify things.

回答1:

If that so, then why would the hacker recover the password if he already has access to the database?

Reasons are many. Here are a few:

1. People reuse their passwords, so not leaking everybodys real passwords does limit the impact of such attack.

2. Without the real passwords, the hacker will still not be able to log in and, say, post new entries on the hacked system.

3. Who says all information is stored in the database? What if the database solely consisted of the user name and hashed/salted passwords? Then, knowing the content doesn't help much.

回答2:

If you have the cleartext passwords and e-mail addresses from the database, you can wreak havoc! It's not about getting credentials to the site that is already hacked, it's about getting login information to other sites.

Most people don't use one password only for one site, so if you have the password for their primary e-mail address, you probably have access to ALL their accounts on every site (through password resetting).

回答3:

To be in possession of the user records from the database does not necessarily mean you have access to the database. Through some leak in the website (hello, SQL injection) you may be able to get access to data you shouldn't have access to without necessarily compromising the whole server. Badly handled backups, shared servers, incompetent or malicious employees may all make that possible.

Also and possibly more importantly, you need to protect your customer's passwords on other sites. People unfortunately reuse their passwords all over the place. If your tiny chat room database gets compromised, people's passwords at their banking sites may be compromised with it.

回答4:

Salt is used so that identical passwords have different hashes, making an attempt at figuring out the passwords harder.

Hashing makes it so that generating the password via brute force methods take a very long time (especially with SHA2) so that it makes it "unfeasible" to find out the password.

A hash will do you no good if you don't know the password as typing the hash into a password field will not work (obviously).

Usually hackers only find users tables and maybe some basic information but if they want to be able to actually access that users info and change something then they need the actual password (since they don't know the whole DB schema changing something could look very suspicious and is easily traceable unless you legitimately login as the person)

One last thing I forgot about is that people do reuse passwords. So maybe you hacked some random site that has no useful information on it but the person used the same user/password combination on their online banking. This could be very bad as you can see so not being able to easily discern the password is key.

回答5:

Suppose an attacker somehow gains access to a backup of the database, containing unrecoverable hashed passwords. Then they have all the data that was in there yesterday, which is quite bad. But at least they don't have access to the data that will be in there tomorrow, and they can't delete anything from the real site, deface it, serve malware via its CMS, etc.

Suppose an attacker gets everyone's plaintext passwords, especially if that includes the administrator. Oops.