What to do when your company doesn't encrypt passwords

Question

Background

I'm been contracted to help a company maintain their server. I work on some minor PHP projects but also look over performance issues and recently, scan logs for hackers.

These guys have been running their server for some time and have what I would call a legacy application on its last legs. It uses magic quotes, global variables (which allows $id to be overwritten by $_GET['id']), use .htaccess as their only security in some instances, you name it. A security and programming nightmare.

We have been hacked in the past, mostly with SQL injections, which would run SLEEP(99999999) commands and act as a DOS-attack. Luckily they didn't run "little bobby tables",

XKCD: http://xkcd.com/327/

So I re-wrote their vulnerable SQL statements from mysql_query() (not mysqli) to PDO transactions. I'm also analyzing the queries for SLEEP and UNION, which we don't use but the injections have. So far, so good.

Latest Issue

Recently we've been told records are changing in the DB for users, such as their e-mail addresses to ones presumably made by spammers.

I noticed their columns didn't have a last_modified column, so we weren't able to even know when they were being changed, let alone by who. I added that column, but that's barely a first step.

When I was looking in to this table, I noticed the passwords weren't salted nor even hashed, just saved as plaintext.

Client Communication

How can I approach them about the entire situation, as a contractor, without flailing my arms like a madman? Any advice? I was thinking a calm approach of,

    ISSUE #1
        Synopsis
        Why this is an issue
        What can happen if this is not fixed
        Suggested fix

    ISSUE #2
        Synopsis
        Why this is an issue
        What can happen if this is not fixed
        Suggested fix
        

Answer 1

The calm approach that you suggest would be best. Pointing out that when this data gets exposed, most of your users will be vulnerable to identity theft due to password reuse. This would be a pretty good time to point out that this is the same issue that affected Target (assuming that the company isn't Target). And your manager should be pretty receptive to changing this.

In regards to legalities with the data, I don't believe that username/passwords are considered the same as CC Data, Personal Information, etc. Though it could depend upon what ever information that you have for your users. I am not a lawyer and these aspects would be best brought up in your revelation and should be brought to your companies legal department to determine legalities.

https://en.wikipedia.org/wiki/Information_privacy_law

And you have this XKCD to help you out too:

Answer 2

It really depends on the audience in which you are trying to approach with this. I have worked in companies with severe security issues like you are stating yet they refused to hear it until I showed it to them.

One approach, if feasible, is to put together basically what you are intending to do as will as itemizing what has already possibly happened in these hacks. If your audience is non technical you probably need to point out the business cost that these compromises can have. Obviously hacked accounts reduces credibility in your system and perceived customer value of your product. Not to mention a compromised system with plain text passwords and email addresses for users can cause a serious rippling effect.

The next thing you should do, if at all possible, is prove it. If you can stand this system up in a test environment do it. Then demonstrate in front of them the kind of impact you can have on the system from the client side of the application. Even with tech people this has proven to be pretty convincing for me (though they still didn't usually act in my cases).

Of course, like you said, you need to explain if anything what measures should be taken and an estimate on the effort to accomplish that. It will help them justify the cost though some places simply just won't care anyway. At least you can clear your conscious and move forward knowing you tried.

Answer 3

If as you say you've been contracted to maintain their server, surely this contract must include in the job description tasks such as ensuring the integrity, security and availability of the operating system, applications software and all data etc?! If there is even a vague hint that the contract expects (and holds you responsible) for making sure the server is secure then I wouldn't waste time putting business cases together and just do a good job of making sure the issues are rectified (taking a backup before and after, keeping a version history of your code changes).

I wouldn't expect a change like this to take more than a morning's worth of work and if they ask what you've spent your time working on then you can keep a journal to explain and justify your actions. Provided you are working within the scope of your contract there should be no issues here. Sometimes going all security crazy in front of decision makers causes panic or in the worst case creates an opportunity for them to say they don't care about those issues so don't fix it, meanwhile you contract still holds you responsible in the event of a breach! Perhaps this isn't always the most business-friendly approach but my professional ethics would not allow me to leave unencrypted passwords in any system I've ever been responsible for having had it come to my attention.

From personal experience I tend to find whenever I start working for a new employer or client, discussing scenarios and expectations upfront can save a lot of stress on your part, for example: if I find any security problems that I can fix are you happy for me to go ahead and complete this work without coming to you every time, only notifying you of suspected breaches/incidents? They will almost always say yes to this because from their point of view they're not interested in worrying about security or computer stuff - that's why they've hired you! Perhaps this doesn't answer the question in the way you were expecting but I hope it gives food for thought. Wish you all the best and hope the issue gets rectified!

Answer 4

Surely if changing customer's email address is already happening, and that is considered a problem - then the ability to change passwords is also a problem.

Now, if you've secured the DB sufficiently to prevent this from occurring in the future, then the chance that anyone can edit the user's password is similarly fixed and you only have to consider whether someone can read the password now.

Of course if they can, or if (in the unlikely event) that you haven't totally secured the DB then surely encrypting the passwords should be done - how to do it? Just put it in the same context as the "having email addresses updated" problem. Whether this requires the application to change, and whether that is a "too-difficult" problem is another matter that needs to be raised with them. Look at the code and see how much the cost of changing it will be before taking the suggested fix to them.