I look after a system which holds a lot of "low grade" information, nothing financial but name/address/email etc. Someone has suggested that we up the security from the current in house password encryption algorithm to use ICO recommended hash/salting. I've done a bit of reading around and am struggling to see the benefit, my argument has gone back to the "experts" who are suggesting this but they wont (can't) answer my fairly simple question.

As far as I can tell, hashing/salting prevents the password being read and decrypted by a hacker, and it's excellent for this, no argument. But unless I'm missing something, in order to read the password value the hacker has to have access to the database so they can steal the password values?... if they have access to the database then they don't actually need the password(s) as they can just steal the data direct from the database i.e. the application access they gain from the passwords would give them nothing more than reading the database direct?...

What am I missing?

Users often use the same passwords on multiple sites. Your site might not have any financial data, but what if the same password is used for their bank, or for an online store?

You could argue that this isn't your problem, but it is a common issue, and is why whenever a breach happens, one of the immediate statements is "change your password, and change it on any other sites where you've used the same password".

If your site used something like Bcrypt (without flaws in the implementation - see Ashley Madison), the chances of an attacker being able to work out what passwords have been used is slimmer, and it increases the time for users to be able to change their passwords elsewhere. If you just store the password in your DB without any hashing, an attacker can wander off with the email addresses and passwords and start attacking another site immediately.

Email address and password pairs are often traded between attackers too, in the form of "combo lists", which means that even if the original attacker is only interested in your site, they might be able to get some benefit by selling the data to someone else.

Added in response to comment on question mentioning 2-way encrypted storage

The problem with a 2 way encryption approach is that the information to decrypt must be stored somewhere in the system. If an attacker gains access to your database, there is a good chance they have access to your encryption key too. A hash can't be reversed in this way - online tools for reversing hashes effectively look up the hash in a pre-computed list.

Even if they don't have the encryption key, they might be able to work out what the key was - they can use a known plaintext attack by entering a password to your system and seeing what the result is. It probably wouldn't be a quick process, but it could be worth doing if there were any high value targets in your data (celebrities, politicians...).

On the other hand, with a strong, salted, hash, the only way to find the original password with strong certainty is to hash every possible input, using the appropriate salt. With something like Bcrypt, this would take years, although weak passwords will still be found relatively quickly.
