views:

500

answers:

8

I've always been of the impression that storing passwords in a database as plain text is (as someone else here put it) a Very Bad Thing™.

Historically, most of our server-side coding needs have been contracted out to a group of programmers. They store passwords in MySQL databases in plain text.

As the resident code monkey (incidentally, the first server-side-savvy monkey to work here, so I'm inheriting the earth, so to speak) I have this pit of the stomach feeling that it's my bum that will be on the line when this plain text nonsense is exploited.

I tried to explain to my boss how very very bad plain text passwords are, but it dawned on me: I don't think I've ever really know why they're so bad. Is there more to it than handing your hackers a list of passwords on a silver platter? That sounds bad enough for me, but in la-la land, where our websites are "secure" and impervious to any hacker, this argument doesn't seem to cut it. How can I convince (or scare) my boss into demanding hashing on his treasured websites?

Related: Encrypting/Hashing plain text passwords in database

+15  A: 

Tell him to consider that in many companies, security problems come from inside rather than out.

Now ask him how he's going to explain to his customers how hackers have stolen their passwords (which no doubt they used elsewhere) next time he has to fire someone for some reason.

Also ask him how much he thinks his customers would like to know that their passwords are visible to anyone with read access to the database.

Jon Skeet
Excellent. Forget cross-site scripting vulnerabilities, etc. What about the disgruntled employee who decides to "borrow" a few passwords after his last day of work... or the random stolen laptop or "lost" backup tape?
Robert Cartaino
Doesn't this sound like a threat? "You wouldn't want something bad to happen to your customers when you fire me..."
jrockway
"You wouldn't want something bad to happen to your customers when you fire me..." sounds like something that would get you immediately escorted off the premises!
Zoe
Yes, you would indeed want to make it clear that you weren't *personally* a threat, of course...
Jon Skeet
In a Homer Simpson voice: "Or am I?"
Colin Mackay
+3  A: 

If 'handing your crackers a list of passwords on a silver platter' is not a good enough reason, what constitutes a good enough reason?

William Pursell
+1  A: 

There are just too many cases of databases with plain text passwords being stolen: If it can happen to reddit, it can happen to you.

Sinan Ünür
+7  A: 

Here are a few reasons:

  • Someone might break into your site. It may be unlikely, and this probably won't sway your boss (I can hear the conversation now: "Are you saying that the site isn't secure?") But it happens, and remember, no one ever thinks that their site will honestly be broken in to...
  • Casual viewing of the database by insiders (like yourself): You might not be TRYING to look at anyone's passwords, but you might, during the normal course of your work, need to look through the table containing the passwords. Considering that many people use the same password for absolutely everything (including possibly your boss!) you wouldn't want all of those passwords exposed. Ask your boss if he has ever reused a password on two different sites
  • If anyone ever found out that your application didn't encrypt the passwords, they might seriously question the trust of your application
  • It costs basically nothing to hash a password (preferably with a salt) into the database, so why not?
Adam Batkin
A: 

The two good answers I have seen promulgated for this question are:

  1. You protect the passwords from snooping employees, i.e. people that have legitimate access to the database cannot easily steal a password should they feel so inclined,

  2. A application logic flaw, such as an SQL injection one on a web site front end, will have a reduced chance of resulting in a compromise.

In my opinion it's a good idea to encrypt database password (although I'm yet to get around to doing it for most of my apps) but of far more importance is to make sure your database server is as bullet proof as possible with respect to network and authorised access. If an attacker can get to your database then it won't matter what how you've stored your passwords they will be able to break them.

sipwiz
"If an attacker can get to your database then it won't matter what how you've stored your passwords they will be able to break them."This might be the programmer's logic. So much faith in their ability to secure the server they think they can save themselves a few hours and lines of code, what will it matter in the end?
Zoe
Not at all. Both measures should be taken, secure the server AND encrypt the passwords. My point was that of the two measures securing the server is the most critical.
sipwiz
+2  A: 

Besides the security risks, I wonder what your clients would say if they found out every employee of your company has access to passwords. When it comes to possible leaks, the passwords are at risk if:

the database is backed up by an external company

the operating system that the db software is running on has any security risks

security flaws in any other hardware or software firewall

any users that have access to the db somehow get a virus that could exploit the data

the db happens to be on a computer or laptop that is stolen

a disgruntled employee is fired and decides to "get back"

every once in a while you'll hear of businesses that store sensitive information in plain text and it never ends well. we're all human and prone to error, you can't assume perfection when it comes to security. you won't find any large, profitable company leave room for any risk that can be avoided since anything bad that can happen, will happen...

Mark Synowiec
+20  A: 

In the military it's called "Defense in Depth". The theory is that you harden every layer you can rather than hardening just one layer and hoping it's enough.

I've heard databases like yours called "hard on the outside, soft and chewy on the inside". There are a million ways a dedicated hacker can get access to your database. Social engineering, a disgruntled employee, an ex-employee who decides to see if his login still works, or that backdoor he wrote is still there, one missed OS patch... the list goes on.

If a bad actor gets access through any of these methods, instead of just getting the data, he gets access to every username/password combination of every user of your system, and as someone pointed out, people often use the same combo for every website. So your hacker goes out and owns hundreds of people's Paypal, email, and bank accounts.

Have I painted a gruesome enough picture yet?

Jason
Beautifully macabre!This is great boss speak; nothing technical (boss' eyes glaze over at the mention of sql injection), and really hits home.
Zoe
Reminds me of an advert: What's "hard on the outside, soft and chewy on the inside"? Armadillos!
Colin Mackay
@Colin Mackay: Where I come from, armadillos don't have an inside. They're just flat. Usually with tire tread marks running through them.
Michael Myers
+4  A: 

You may wish to point out that failure to properly secure the accounts could be exposing the company to legal liability if the information were ever compromised. Ignoring a known vulnerability could wind up costing you in legal fees if a user's data was exposed as a result of your company's actions (or inaction, as the case may be).

In the United States, there are certain types of data, such as financial and medical information, that companies are legally bound to keep secure and private. Failure to do so can have serious consequences. I'm not familiar with other countries' laws in this regard, but it's something worth looking into if your company is dealing with such data.

Jeromy Irvine
Good point, I'll look into what similar laws we have in Australia. Thanks!
Zoe
+1 legal considerations
gorsky