24

My employer asked me to implement a feature that would require storing passwords in clear text in a database (or using an obscure encrypt/decrypt function stored in a binary, which is a bit better, but also insecure).

I replied that I was willing to implement such a feature, provided that customers were acknowledged of security implications when using it.

When discussing this problem with colleagues, someone told me that, as a software engineer, we are personally responsible (in the legal sense) for security problems that we introduce in our products. I looked into my contract, but did not found anything related to a similar case.

From a legal point of view, should I refuse to implement such a feature? Is it true that my employer could take me to court if a customer experiences damage due to this feature, even if he was aware of security concerns as well?

EDIT: I understand this question can only be answered reliably from a lawyer. The same is true for licensing questions: people here give their understanding and their experience, sometimes after having consulted a lawyer, with no guarantee it applies in another jurisdiction. But licensing is explicitly accepted as a topic here, see What kind of questions can I ask here?. I believe other programmers may have the same issue, and other may have been confronted to this situation before, and may have consulted a lawyer for that.

Improve this question
12
  • 2
    You should contact a lawyer - this is not the right place to get an answer.
    – Oded
    Commented Nov 6, 2011 at 12:45
  • 11
    IANAL, but it seems unlikely that an employer would be able to successfully sue an employee for doing exactly what they told him to do.
    – user31664
    Commented Nov 6, 2011 at 13:21
  • 3
    @Oded: the client could sue the company, yes, and the company might still unfairly blame and fire the employee (in an "at will" jurisdiction), but I've never heard of customers being able to sue individual programmers. The company is the legal entity which entered into the contract of sale, not the employee, so it is the company which is responsible for quality issues in the product.
    – user31664
    Commented Nov 6, 2011 at 13:42
  • 8
    What could lower the confidence your customers have in your solutions more than storing a password in plain text?! Absurdity. If your boss is going to ask you to dig his own grave then just do it, but make sure that you get it in writing in email that you informed him of your disagreement and warned him of the potential consequences, and also him ordering you to do it anyway. Keep that correspondence with you always.
    – maple_shaft ♦
    Commented Nov 6, 2011 at 16:27
  • 3
    I'm voting to close this question as off-topic because a legal question that can only be properly answered by a lawyer.
    – user40980
    Commented Feb 26, 2015 at 14:42

11 Answers 11

Reset to default
11

Your colleague is misguided, especially since you couldn't find anything on security responsibility in your contract. Even if it did, you just got a conflicting order from management.

I think the only time you subject yourself to potential litigation is if you knowingly damage the product yourself, create your own time bomb, easter egg, etc.

On most cases, the company owns the software, so they get to enjoy the profits, but it also means they get to take on the risks, too, not the individual developer.

Personally, I would make sure management was aware of the issues with this security feature, so that it was documented beforehand, and just continue to do my work.

That being said, consult a lawyer, yada-yada-yada.

Improve this answer
34

Whatever happens: Never write such code without having an email or other evidence showing clearly that you just followed the instructions of your employer.

Improve this answer
6
  • 6
    And print it off/send it to an outside account too.
    – Bill Leeper
    Commented Nov 6, 2011 at 23:24
  • 7
    Known as CYA (Cover Your A..). I once emailed a copy of the objectionable instruction to my personal email account, and sent it to the companies legal division (We had an ethics team so this was confidential). It depends on how much heat you are prepared to take, and how much "protection" you need. Others worth thinking about are Marketing, The Board (ultimate responsibly), The Owner/shareholders. Ask "Who has the most to loose"? It will be career limiting, as you have either wasted a lot of important peoples time, or made you boss look bad.
    – mattnz
    Commented Nov 7, 2011 at 1:18
  • +1 - cover your back. Document your objections and reasoning as to why you think this is bad. Document your managers response. Print this out and file it carefully in case the heat comes back to you.
    – Qwerky
    Commented Nov 7, 2011 at 10:46
  • CYA but don't be passive aggressive about it. Make sure you voice your objections BACK to your employer and save that email too.
    – Doug T.
    Commented Nov 7, 2011 at 17:22
  • Plain and simple - I like this answer. This would definitely help with responsibility legally, however, you'll still have to make the ethical decision yourself.
    – stringo0
    Commented Nov 8, 2011 at 6:56
6

From a legal point of view, consult a lawyer. I'm not one, nor do we have any clue what jurisdiction or laws you live under which might help explain some things. But in any case consult a lawyer, would you trust an internet Q&A site with your personal, professional and financial future.

The general business advice is make sure you get your reservations down in writing and your employer's direct order to continue given the security concerns in writing. If things do go south and hit the fan you will have that to fall back on.

Another way around this would be to look deeper into the requirements -- you've shared the plan not the problem you are solving. There are more than one way to skin a cat, or handle password lookup requirements.

Improve this answer
3

I wouldn't worry about it - it's not like you're maliciously deciding yourself to put the insecure feature in and exploit it yourself later, or just put it in because you're negligent. The company wants this, someone has decided the trade off between development time and user expectations is acceptable (as usual) and so you should get on with it. If you are really worried about any comebacks, send your boss an email and keep the response. Once you've done that, as an employee, you're covered.

Sometimes there are reasons why this is acceptable - for example, I know of some very mission critical solutions that store plain text passwords, but the rest of the system is secured so that this doesn't become a problem. This system is on a separate network for example. If you don't know the rest of the story (a common situation in most companies) then you can reasonably expect that someone else has considered this. Similarly, if you have that email from your boss, you can expect that he knows what he's doing.

Incidentally... is this a product I (as a consumer) might use? If so.. what is it, so I can avoid it? :)

Improve this answer
0
1

Do we realize that numerous bugs are added by developers which does harm the customers during the live operations to equally great asset. We don't think they are intentional but it still is a result of some of our concrete work and still not to the mark. So the example you have made is not an isolated case, where developer's (or higher ups) decisions does affect the client.

Here is what i suggest:

  1. First off, by all means - it is the company who is delivering the software to the other company. An individual is not given a direct credit (beyond applause within the team and paycheck at most) and ownership of the work. So while this is not a good thing as a part of our delivery, but you are not the criminal here - as long as decision is not yours.

  2. As a professional programmer - you would clearly indicate the limitations of the code and dangers involved in how to maintain things as part of README file or documentation involved. If there is a requirements document - the suggested test report etc. should clearly mention the limitations.

  3. In order to hold the true decision maker to be responsible- i would request the higher up to confirm their thinking in the email of any such documents.

  4. Weigh the risk correctly. My data card software does store the password in plan text but that is not important. But the same is not acceptable if i am storing bank password or if it is access to database or server. So based on real risk, you must escalate the issue to higher up as much as possible.

Improve this answer
1

Unless you perform your job in a wilfully damaging manner there is little legal downside to doing the tasks asked of you. You will have a contract of employment that will state your liabilities, you can consult a lawyer on the technicalities. Get written approval of the design decision on plaintext passwords if you really feel exposed.

I won't reveal which software it is until I'm sure this feature makes it in the final release. I still have hope we manage to inform customers in a way I find it acceptable.

A little more worrying is your quote about 'informing customers'. If you damage your companies standing, reputation etc (a clause about which will be in your contract) then your company could sue you - and a 'whistleblower' defence might not help you when you need a reference or another job.

If you are unhappy about the implications of the security holes then brush up your resume and move on, but if it wasn't your decision and its not your company I can't see why this would be 'blamed' (legally) on you.

Improve this answer
2
  • 1
    Thanks for your answer. I expressed badly in my comment. I wouldn't be happy with this particular decision, but it doesn't makes me angry against the company or anybody. Making that public in a Q&A site would definitely be a bad idea. It would be negative advertising AND there is very few chance it would help anybody.
    – Antoine
    Commented Nov 6, 2011 at 16:07
  • It's good that there is a forum like this for you to vent - I hope everything turns out well.
    – amelvin
    Commented Nov 6, 2011 at 22:02
1

Your company should have taken out a form of professional indemnity insurance when they employed you. This should provide adequate legal protection for all its employees in case of anything going wrong with the software, or misuse of software or flaws being found in the software (such as unencrypted passwords).

As an employee you are supposed to do what they ask, and they are supposed to do what the client wants, as long as neither party are breaking the law, there is no problem, but if you do what the company wants, and then it is found to be not what the client wanted/required, then that is between them, and the professional indemnity insurance should cover you from any personal blame/liability.

IANAL, but i would take this up with the companies legal team, in addition to checking with your own lawyers.

PS, if you are seriously spooked by this, save all relevant emails in electronic & hard copy somewhere off-site if possible.

Improve this answer
1

Time for a new job. Forget implementing this. It's time to move. If they are willing to be so cavalier and deceitful with this, they won't be afraid to throw you under the bus either.

Additionally, don't be afraid once your gone to anonymously contact one of the many groups that point out security holes in peoples software. This is a disaster waiting to happen. There is absolutely no sound reason to store these. Did your boss give you a reason? Do they want to login as the users? Do they want to make it easier to retrieve passwords? Unless you get an answer to one of these above that you can address more securely, then it's time to move on. When you leave, it would be best to not tell them why.

Improve this answer
4
  • You do realize that even Google stores passwords in plaintext right? If you are the administer of an site you can see passwords of the accounts.
    – apscience
    Commented Nov 11, 2011 at 3:59
  • 1
    Um, I don't think so. You don't store the passwords. You do a one way hash that can't be reversed and store that. That's the standard way of doing it. Even the recent hacks where accounts were compromised did it that way. Main issue there is if someone gets the hashes and knows how they were generated they hit it with a dictionary. But NO NO NO, you never, never, never, never store the passwords themselves even encrypted. Just asking for trouble with that one. Want to know more. Go here: owasp.org/index.php/Main_Page
    – Bill Leeper
    Commented Nov 14, 2011 at 2:32
  • I'm pretty sure google does. If you are apps administer you can look up all of your user's passwords. See google.com/support/forum/p/Google%20Apps/…, answer #4.
    – apscience
    Commented Nov 15, 2011 at 4:20
  • 1
    RTFA. Sorry, it says YOU can login as a user. This is a method where a user with certain privledges can impersonate another user. At no point does google give you the other person's password. You are logging in with your own credentials and then impersonating the other user. This is pretty common and is one solution to my original comment where the boss may want to login as a particular user.
    – Bill Leeper
    Commented Nov 15, 2011 at 19:40
0

what you can do to follow directions to store passwords in a recoverable format while still being impossible to retrieve if you have full access to the program is using asymmetric encryption

you encrypt the (salted as always) key with the public key stored in the binary

and when the passwords are needed in plain-text a human needs to provide the private key that is otherwise kept secure away from the server

Improve this answer
1
  • Depending on the reason for the demand, this might not come anywhere close to satisfying the OP's superiors.
    – user
    Commented Nov 7, 2011 at 9:03
0

Personally, I've never heard of a software engineer, without a clause in the contract or other formal agreement, being held legally responsible for security problems in products they work on. From what I've read about laws and ethics in software engineering, the security requirements for a system are dictated by the requirements specification, which also refers to any legal, industry, or corporate requirements. When building a system, failure to meet security requirements is treated as a failure to complete the terms of the contract as the system was not built as specified. How the specific events unfold depends on the contracts between the engineer and the employer and the employer and the customer.

Laws also don't tell you what you should do, but what you can/can't do. You don't mention what industry that you are in, but some do have laws, regulations, and rules as to how to handle specific types of data - what has to be encrypted, minimum levels of encryption, requirements for managing/controlling access, and so forth. If your area (country, state) doesn't have rules about security, your industry doesn't have rules about security, and the software requirements don't call out security requirements or standards, it might be more of an ethical issue than a legal issue.

When it comes to ethical issues in software development, I subscribe to the Software Engineering Code of Ethics and Professional Practice. Ultimately, it's your call. However, I feel that storing passwords in plaintext or in a format that can be decrypted is unethical.

Improve this answer
-3

Just conform to the development process of your project: if this feature is written in the requirement document, you shall implement it.

Improve this answer
2
  • Just following orders sir. I don't think so. Programmers are hired to think, ask questions, be creative. It's crappy software like this that gives the industry a bad name and jeopardizes our personal information.
    – Bill Leeper
    Commented Nov 14, 2011 at 2:40
  • My answer suggests exactly the opposite: if your boss is in contradiction with requirements, then you can safely bypass the boss. I doubt that in the case exposed, the boss would accept that his order be written in requirements.
    – mouviciel
    Commented Nov 14, 2011 at 8:19

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