Why are only passwords hashed?
Some things first:
- Forget about MD5 immediately. It's old and weak.
- Ideally, forget about SHA1 too. There are SHA2 and SHA3.
- This hash algorithms in their pure form are useful for many things, but not for passwords. Use them in combination with eg. PBKDF2, or use bcrypt (and don't forget salting).
So, if I am not wrong passwords are hashed so that in a rare situation of your database being compromised a hacker can not see all the passwords in your database as the passwords are hashed.
Correct. While this won't help making your server more secure (after all, it's already compromised in such a situation), it prevents eg. the attacker using the passwords on other sites. Sadly most people use one password for multiple things.
Is hacking a database that easy? I mean instead of finding new ways to hash, why can't they make their database more secure or "hack-proof"?
You could (and you should). But:
- Even with all your efforts, there always is some chance the attacker can get access. Bugs in software and devices you don't know about and/or you can't fix, and many more things.
- Often you can't give your best because of managers who don't think security is important, have no budget for it etc.
If a hacker manages to hack into some database, why would he want to know the hashed passwords? I mean he can change other columns of data. For example, he could search for his username and increase his bank balance. So, shouldn't all the fields be hashed?
If all fields are hashed, the database is useless for you too; so you can't do that. Remember, a good hash can't be reversed.
As said above, as soon as your DB/Server is compromised, the damage for you already happened. The hashed passwords just prevent that the attacker gets access to other accounts of your users too (and then some users would sue you, so hashing helps you too).
MD5 and SHA-1 are no longer safe not because "most password hashes are now on the internet." The use of salts to make password hashes globally unique in fact makes this impossible. They are obsolete because they are too fast, and too many candidate passwords can be tested against a stolen hash too quickly for comfort.
The downside of hashing is that it isn't reversible. This is why it can't be used for all sensitive data. You bank balance, for instance, isn't much good to either you or the bank if it is hashes, and neither of you knows what it is.
While it's probably not that easy with well configured systems in mind, multiple vulnerabilities either on the OS or application level (like SQL Injection, possibly even a file inclusion) may lead to database compromise, as is quite often the case in reality. Protecting passwords by hashing them is an example of defense in depth. Even if a line of defense fails, it should still be relatively hard to get to actual passwords.
Passwords are a good target for multiple reasons. On the one hand, they allow impersonation of users, rather than reading, changing or deleting data with the attacker's (possibly compromised) account. Also users tend to reuse passwords, so a password stolen from one application has a very good chance to be valid for other accounts of the same user. As for why other data is not hashed - hashing is one way, you cannot get back the original value from a hash (at least not trivially, in reality and with many hash functions, you have a good chance, but let's disregard that for a moment). Being one way means that hash functions are good for checking whether a password entered is the same as the stored one, but it is not good for storing data that you actually need in its unencrypted form. And that is the solution you may have been looking for, encryption, as opposed to hashing. It is indeed a good idea to encrypt sensitive data in a database, but that too has its own problems, for example key management.