You don't currently hash or encrypt the passwords?

We encrypt but using a 2 way approach

Passwords should be hashed (not encrypted, please) because: 1. human users reuse passwords on other sites/systems, and 2. we want to prevent attackers who got a read-only glimpse on part of the database to upgrade their powers into read-write access to the rest of the database.

You can just reinstall everything in case you believe someone hacked your system. But if the database containing passwords is lost, the users can no longer prove they are themselves permanently.

Irony not appreciated!... not everything needs to be nailed shut, security needs to be appropriate to what is trying to be protected + the budget for any work (zero in this case). We are not talking a commercial system here. To me encryption is better than plain text but not as good as hashing... I repeat, if the backend database is SQL and the attacker gets the passwords from the user table then they have the rest of the data anyway.. or do you guys connect to the users table with one SQL account and then allow access to the rest of the system with another?

Here is why that argument fails: xkcd.com/792 you can't guarantee that your users are just using that password on your site

I understand that, but if it's a non-commercial "help" site, with a login to allow users to store preferences and receive mailshots etc, written by one person with a few hours to spare a month, what is the option?.. close it or put up a notice explaining the dangers of registration?

the application access they gain from the passwords would give them nothing more than reading the database direct? Once they have the passwords, they can then impersonate other users and therefore (A) continue to access the database after the exploit they originally used to read the database gets fixed, and (B) edit the database once they figure out which user has edit access.

@Steve, I'm not going to post an answer because it would get downvoted to shit on this site, but the fact is you are right. While good security isn't hard to set up, it isn't trivial and neither is keeping it up to date as standards change. If you don't have anything worthwhile in your DB there is no reason to jump through hoops trying to secure it, aside from the password reuse point someone already brought up (and is very valid!). Keep in mind, though, you basically came to an auto repair site asking Does anyone think I really need a car or will a horse do?, so you're going to get bias.

Passwords are not yours, they belong to your users. Salts protect their passwords from you. (and, as a side-effect, from anyone who hacks you)

In case some other technology screws up and they get your password file, hash and salt prevent them from getting the passwords themselves for a while. So, unless your other technology is perfect, the hash and salt is extremely helpful.

An attacker may obtain the password table by means other than hacking the server. They could be given the file (and encryption keys) by an employee (and you would never know). Or if the hack remained undetected the original hacker might distribute the file to others, giving more people access than just those who hacked the server. If the passwords were hashed & salted it would be much less use to them.

I can't see any mention of your coworkers in all the comments and replies. They have access to decrypt user passwords, and they shouldn't have. They have access to login as any user, and all audit logs will show that the user changed their own address. They can sell the email/password pairs to criminals. They have minor leverage against the company with "__ or I will prove to users that their passwords are 'insecure plain text'". With a SQL attack someone gets any data - once. With passwords, an attacker gets data access through the front door forever, and no log will notice anything odd.

OK guys thanks for the comments, I'll take away what's useful for the site I'm working with and store the others for other work as appropriate.

Names and addresses are secure information. Take a person who is being stalked by an abusive spouse as an example. Leaked credit card details can ruin someone financially. A leaked name and address can (probably won't, but can) get someone killed.

So what's your point... I should hash every field?

@Steve Encrypting isn't better than Plain Text to an attacker. Encryption is 2-ways, and the decryption keys have to be accessible to your server (and therefore to your attacker). Might as well just store them in Plain Text if you really are going to resist and argue with industry standard practices.

No, hashing everything would be foolish. I'm just pointing out that simply because you can't think of a way to use data maliciously that the data is "low grade". You're clever enough to realize that there are people out there who do bad things with innocent data; I'm trying to help you make a realization that many, many clever people have had to come at the hard way, when they learn how their disregard for the mundane has been used to hurt people.

not everything needs to be nailed shut, security needs to be appropriate to what is trying to be protected + the budget for any work (zero in this case) - Yes, tell that to Sony or any of the other companies hacked last year who thought they were too small to be a target and/or the cost benefit wasn't great enough (how does a $10MM class action lawsuit sound to your budget?) Furthermore, low/no budget is not an excuse for shoty quality. Just do it right (or tell us which site you're working on so we can all avoid it).

Access to people's passwords also grants you the ability to impersonate them and process activities or transactions against their wishes. The existing database is not the only thing the will have access to.

Just gonna throw out there that if the problem is the extra work of writing hashing or salting its probably just changing where you encrypt to hash and you can use your old encryption key as a salt

@Agent_L: what do you mean by "salts protects their passwords from you"? If the website owner wants to see the passwords he/she will always be able to do that. They are the one running the hash algorithm (starting from the clear text password) at each login after all.

@wil93 You are hasing a salted password, hence you would need the password to generate the hash. Since you don't store the plain text password but only the salt and the salted hash, you don't have the plain text password. The website owner can reset the password of course at any time and gain access that way, yet that is not the point. Making it hard to get the plain text password is. If it is hard for yourself, then you are doing it right. (That's why good encryption site never send you your password, but a link to change your password.)

Very relevant to this topic: youtube.com/watch?v=8ZtInClXe1Q

@k0pernikus yes but what I mean is that I can't protect my users' passwords from myself, like, I can't say to them "I hash your passwords, so don't worry, go ahead and type your password, I can't see it".. they just have to trust me that I won't steal it :)

This looks like a duplicate of "Why is using a salt more secure?"