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
        Why this is an issue
        What can happen if this is not fixed
        Suggested fix

    ISSUE #2
        Why this is an issue
        What can happen if this is not fixed
        Suggested fix
  • My Thought is, regardless of plain text passwords which is a massive no no. If you have changed all queries to PDO and are using prepared statements, unless there is a change your email ect section. They should be unable to execute an SQL query to change email addresses ect Feb 4, 2014 at 18:26
  • 1
    I didn't change /all/ queries to PDO, sorry, I changed the ones we found were being affected by SQL injections.
    – bafromca
    Feb 4, 2014 at 18:31
  • Would a better solution all round be to add a PDO class and then implement that class through out the site? then think about hashing passwords, and using a salt however this maybe a little time consuming as you state it is a "Legacy" app i'd assume it has a fair few users. Feb 4, 2014 at 18:36
  • 5
    I'd say revise your 'what can happen' to 'what has happened' since they've been hacked already and the users credentials have been released into the hands of hackers. Feb 4, 2014 at 18:48
  • It seems your question is just about communication with your client. Honestly, you should know your contact persons and how to approach them. Keeping calm is always a good strategy, just point the risks out to your client and let him decide about the urgency.
    – Doc Brown
    Feb 4, 2014 at 18:54

4 Answers 4


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.


And you have this XKCD to help you out too:

enter image description here


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.


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!

  • That's a great answer. Sometimes bringing up issues with "front-line decision makers" causes more panic than it's worth and it does seem smarter to just fix it behind the scenes. I don't like working behind the backs of who pays my salary but the personal liability issue is a key argument. I could salt+hash the passwords easily and then remove the opentext password column when everything is moved over. However, the biggest problem is that the passwords may have already been viewed and captured.
    – bafromca
    Feb 7, 2014 at 22:33
  • The unfortunate reality is that time cannot be rewound to the point before the breach, so while the business will perhaps need to decide whether they inform their customers of the breach or not, the most important thing to me has always been taking action to prevent further breaches. If the directors don't want to inform users of a breach you could instead prompt customers after login with a message like 'Following improvements made to our website security we now require you to choose a more secure password including upper case, lower case and numbers and a minimum of 8 characters in length:'. Feb 12, 2014 at 17:03

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.