34

I've currently inherited an application at work and to my dismay, I have realized that the user passwords stored in the database are encrypted using an in house encryption function, which also includes the ability to decrypt.

So all someone really needs to do is copy the user table and copy the encryption assembly (anyone with database production access) and then they would have access to 100,000 email addresses and potential passwords for them.

I'm trying to explain to the business why this is not a good idea, but the security concepts seem to go over their head as they are not that technically minded (it's for government). Plus there are actually existing functionality within the application for admin users to retrieve user's passwords in order to log in as them and do stuff (which they have said, they require).

So they don't understand the security implications. And in order to implement a stronger security policy (hashing passwords so they can't be easily retrieved), I have to remove existing functionality for them.

What should I do? I didn't build the password system in the first place, so it's not like I can be blamed if anything does go wrong. On the other hand, I don't feel good about it and I also don't want to have access to 100,000 potential email logons.

13
  • 9
    "which they have said, they require". And they also lie.
    – S.Lott
    May 4, 2011 at 1:06
  • 10
    Whatever you do, just cover your ass.
    – Job
    May 4, 2011 at 1:23
  • 6
    One of the key aspects of security is non-repudiation. I.e. a user should not be able to say "It wasn't me" and be believed. If an admin can log in as a user, that casts a shadow of doubt on the source of any action. Basically, once you have the admin account you can do whatever you want. May 4, 2011 at 16:31
  • 10
    Building the new PSN? ;-)
    – vartec
    May 4, 2011 at 16:34
  • 11
    So tempting to retag this question with "Sony". May 4, 2011 at 16:35

14 Answers 14

60

Implement the functionality they need in a secure way. Administrators logging in as another user can be implemented without them knowing the user's password. They can log in as themselves, and then have some 'change-identity' function available.

Securing a password database is not a business concern, it is a technical concern. Not doing so is a bug. If the business thinks of security as a functionality tradeoff, security will lose. You should not give them any reason to think of it this way.

5
  • 6
    +1 for the second paragraph and the "Not doing so is a bug". I wish every developer would understand that. May 4, 2011 at 0:22
  • 3
    +1 for "Securing a password database is not a business concern, it is a technical concern.". /me thinks some decisions, like this one, should be purely technical.
    – Machado
    May 4, 2011 at 0:48
  • 1
    I still think that administrators logging in as another user violates the non-repudiation aspect of a secure system that most government policies say they they are required to have--as a mandate from executive offices. May 4, 2011 at 16:28
  • I've worked in defense contracting, and I can assure you the government is a lot stricter on businesses that want SOX compliance than they are on themselves.
    – corsiKa
    May 5, 2011 at 5:13
  • 1
    +1 for the change identity this way it is easier to log what he did while pretending to be that user
    – J_rite
    Jan 3, 2020 at 14:27
16

You need to convince them that they really do not need to be civilly liable in the event that their server is broken into. Nor do they need the backlash from an informed userbase that realizes that they are being negligent.

Sometimes there are clear-cut cases where one party is wrong and the other is right. This is one of those times.

Look at what just happened to Sony. Also, our site was hacked recently, and one of the things that prevented it from being an unmitigated disaster was that we used a (relatively) good one-way hashing function (SHA512). We have since switched to bcrypt to prevent even brute force / dictionary attacks (or at least make them untennable). I simply don't find anything else conscionable.

0
8

Fact: people use the same password on many sites

Your boss probably doesn't realise that people often use a single password (or a very limited set of them) for all kinds of services (including banking or Facebook and similar). If users can change their password in your system they are highly likely they use the same password as elsewhere.

If your boss thinks that this password access isn't a problem, you should as well tell them this fact and maybe they will start thinking differently. Even if your app is behind the wall and not publicly accessible it can pose security threat on other online services. Usernames (especially when they're emails) are rather easy to guess. I can't imagine how funny it would be to login to boss' Facebook account and put something on their wall.

User passwords should always be treated as top tier privacy/confidential information that only a limited number of people have access to. It's best to avoid storing such volatile information. And even when you do, you should be granted each single access to this information. Like getting a confidential paper from a highly secure safe that can only be opened with multiple keys. So people know who has been granted access and when.

How to implement account delegation

Account delegation in your application should be done differently.

  1. Admins should log in as themselves and then
  2. either (since they are privileged users)
    • enter only UserName or
    • select a certain user from a list to log in as them

It should definitely not be done by logging into with UserName + Password combination.

It's true that new screen should be developed to allow for delegated logon, but still.

Why is delegated logon better?

You could as well provide additional functionality that would make it clear that some action has been done by Admin on behalf of some user (which you can't know now because Admins act as Gods and login as whoever and may be doing things that can hurt real employee reputation).

You have to agree that people make mistakes. Admins are people as well. And if they make a mistake on behalf of someone else they will try to blame them. I'm 100% sure about it. This will make it safer for non-admin users so their real-world reputation won't suffer from other people mistakes.

5

You don't mention what the application does. If it's passport applications, full of identity-theft information that must be protected, it deserves the maximum protection. But if it's "tell me the traffic accidents on my route home" what are the consequences of a password breach? Some systems I've written don't even have passwords - you just enter your email or your student number or some other identifier that people often know about each other, and the owners of the system value the ease of use and inability to be locked out over the possible privacy breach if people impersonate each other. I have no problem with that, either. Why do I need a password to set up my schedule of preferred sessions at a conference, for example?

So if I was being brought in for code review and you raised this to me, that's where we'd start. What are you protecting? What are the negative consequences of one person managing to log in as one other person? What are the negative consequences of everyone's stored data being exposed? Maybe they're awful. You would list them for me. Then, what are the consequences of people not being able to click "email me my password" but instead having to click "reset my password"? Would they stop using the site? And what about the staff logging in as the person? Is that saving time, money, lost sales or what?

The final piece of the cost/benefit story, and one you get to only if there is a really large difference between the negatives you are exposed to now and the negatives you'll get when you remove functionality, is the cost to fix it. Would I spend a million to spare me the chance of a thousand-dollar exposure? No. What about the other way around? Depends on the odds, I guess, but my first answer would be yes.

ps - the Canadian government went live with an apply-for-your-passport site that had IDs in the URL: if you edited the URL with a different ID, you saw the half-completed form of some random other citizen. And I have clients who sign in as their customers for customer service purposes to general happiness, so I do see the good side of it, though I wouldn't stand for it if the data behind the password was actually important to strangers.

4
  • 9
    Users have a tendency to use the same password on multiple sites with the same username so exposure of a database could prove useful to identify thieves who are willing to take the time to try the combination on financial websites.
    – rjzii
    May 4, 2011 at 0:10
  • 10
    It doesn't matter what the application does. The most sensitive piece of data IS their password. Most users share passwords across multiple systems. If I had their applicaiton password, it would be likely it'd be their email password etc.
    – RoboShop
    May 4, 2011 at 0:11
  • 2
    @Rob Z, @RoboShop, I wish you guys were wrong. Alas, I know you're not. This is a good argument to avoid having passwords on sites that don't need them ... it just encourages reuse of a password that might be meaningful elsewhere. May 4, 2011 at 1:55
  • @Rob Z: or, another example, I recall reading that after Gawker's database was compromised, bots were written to try all of the username/password combos on Twitter, and then post spam tweets from all the accounts that were broken into. May 4, 2011 at 3:24
5

It may be against the law and could open them up to being sued. If they are retain any sort of personal information about the user, or the system interacts with other systems as the user you may need check to see if the system falls under any of the State or Federal Privacy Acts or laws. ie. Sarbanes/Oxley, California OOPA, etc.

Aside from the potential legal problems you can also point out that any admin could at any time dump the entire table to a portable data stick and leave with the ability to login as any user and cause havoc, or sell the data.

Even if you assume all the admins are trustworthy it also makes the compromise of an admin password devastating.

You also don't need a user's password to perform operations as them. You can implement a sudo-like feature.

0
5

This can't possibly be a federal government system as FIPS and FISMA requirements would prohibit reversible encryption for passwords, and the parent department would slap them to the moon.

And in order to implement a stronger security policy (hashing passwords so they can't be easily retrieved), I have to remove existing functionality for them.

For my previous company, I kept fighting for the ability to send password reset emails to get around this issue. And I kept getting overruled. In the end, I got tired of shoveling poop against the tide, so I left. This was also a pointy haired boss who thought that the stupid questions some bank websites ask counted as "2 factor authentication". Arguing with him was like a Dilbert cartoon (he was shaped like the PHB).

Plus there are actually existing functionality within the application for admin users to retrieve user's passwords in order to log in as them and do stuff (which they have said, they require).

I've seen this implemented at a financial institution. The people at the customer support area would log in with their own credentials, and if they had the rights to do so, could pretend to be logging in as the customer. This did not log them in as the customer, just impersonated the customer. That way if the customer service rep decided to withdraw money, it would not show as the customer doing it in the logs: it would show the customer service rep trying to do it (as well as sending an alert to have them fired as soon as the rentacop could make it to their floor).

Done poorly, it would make the customer support staff able to make it appear that the end user engaged in some activity that could result in serious financial or legal liabilities.

The last federal website I worked on collected 1/4 billion US dollars per year from end users (of which there were about 400 users), so the logging had to be very tight, and that only the authorized end-user was allowed to touch the web pages where they reported the stuff they paid excise taxes on.

Sony was one of the companies with the latest security breach. It wasn't just the PS3 network, it was their network of MMORPG games as well, totaling somewhere well in excess of 25,000,000 names, addresses, credit card numbers, usernames and passwords. You can believe that I am not happy at all (I want my evercrack!).

1
4

I reference the Software Engineering Code of Ethics on concerns like this. My interpretation, your first priority is not to undermine public interest (not as in possibility of compromised password more like this example here where a company modified Dell laptops so that the rental company could spy on their renters without them knowing). After that your responsibility is to INFORM your client of potential risks and let them take it into consideration. Of course that's the minimum baseline. You have to use your own judgement of whether you feel that this it still more than you can stand by and allow.

Of course when you mention a government project, if citizens' private information is at risk because of these practices, then it is undermining public interest.

1
  • 4
    And if it's a government project, it may not even be legal to have it that insecure. May 4, 2011 at 1:15
3

You could print out the list of emails and decrypted password and put it on your boss's desk, with a large warning on the cover page: "Confidential"

Make the font tiny so as not to waste paper though.

You could also show them how bugzilla allows admins to impersonate people without using their password.

1
  • +1 for giving an example to the boss. One could argue that would be better to put just the bosses and their family/acquaintances passwords on the desk.
    – Machado
    May 4, 2011 at 0:50
2

First of all, I agree with the other answers pointing out that it's much safer to just avoid this, and only store hashes of passwords, not the passwords themselves, or anything that can be transformed back to a password.

There are times, however, when you more or less need to allow for recovery. In the case of passwords, you generally want to recover by simply allowing an administrator to change the password when/if needed rather than recovering the existing password.

Another possibility, however, is that that you allow the user to store data on the server that's encrypted with their own password. In this case, simply allowing an administrator to change the password is not sufficient. The new password won't work to decrypt the data, and most users will find it unacceptable for all their encrypted data to become inaccessible when/if they forget/lose a password. For this situation, there's an alternative that's reasonably secure, and still allows recovery when really needed.

Instead of using the user's password to encrypt the data, you create a random key to encrypt the data itself. You then store that key, in a couple of places: once encrypted with the user's password, and in another place encrypted with an administrator password. Then when (not really if) the user loses his/her password and can no longer access the data directly, you can use the administrator password to decrypt the real key and use that to recover the data and/or re-encrypt the key with the user's new password.

If you don't want to trust a single administrator completely, you can manage that as well. For example, you can decide that 5 people will have administrator keys, and you want at least three of them to agree before a key can be recovered. In this case, when you store the encrypted password for administrative purposes, you store it multiple times, once each for each set of three of the five administrators (which doesn't take up much space, since you're only storing multiple keys, at ~256 bits apiece, not multiple copies of the data). Each of those copies is successively encrypted with (the hashes of) each of the passwords for those three administrators.

To decrypt it, you need to identify the three administrators who are entering their passwords, and pick the proper encrypted key for that set of three, then decrypt using each of the three passwords to finally get the original key. You can then use that to recover the data itself, or you can just re-encrypt it with the (hash of) the user's new password so they can still access their data.

When you do this, though, you really need to use a standard encryption algorithm, and (by strong preference) a standard, well-known, thoroughly-studied implementation of it.

2

This worries me, given that it's for a government project. Retrieving a user's password to perform an action under their ID makes a nonsense out of any kind of security audit. The only reason I can see for this is to create a fake audit trail.

There's really no need to use reversible encryption for passwords. If there is ever a legitimate reason to spoof a user ID, it can be done by:

  • Store the current password hash
  • Replacing with a known value
  • (Faked-audit-trail-activity, e.g. Transfer funds to offshore account)
  • Replace original password hash

I would be uncomfortable with the last step - whoever was impersonated on the system should know it has happened. Maybe you can persuade the business by saying "It's like your bank letting me access your account without your knowledge, because I said I really needed to"

1
  • +1 for Audit trail, so very important for day-to-day work as well as (hopefully not day-to-day) disasters. People rarely take security or auditing seriously.
    – dave
    May 4, 2011 at 2:00
2

Their belief in a better password system is not the problem. Create a solution to allow an admin/support to impersonate a user account and provide your fix for the passwords. Security often suffers for convenience. Make it convenient and secure.

Edit: They are never, ever, ever going to fully comprehend the password security issue, but they do understand losing functionality. Make this proposal and see if you can get the approval to make the necessary changes. They don't even know if it will take one hour or one year. It's a feature change and not a complete rebuild.

18
  • 3
    This isn't a full answer - how do you justify the cost of doing so? If the business does not believe it is worth it, then the employee would be putting their job at risk by not focusing on higher-priority items.
    – Nicole
    May 4, 2011 at 0:06
  • @Renesis - The cost of security is earned back when your systems aren't compromised or are compromised but nothing of value is lost. The company needs to have a security oriented mindset or it will be an uphill battle.
    – rjzii
    May 4, 2011 at 0:09
  • 1
    @Rob Z - Yes, and I think the question is about how to achieve that mindset. Clearly, the business doesn't believe there is risk (or cost, or both).
    – Nicole
    May 4, 2011 at 0:13
  • 1
    @RoboShop No, if the password is retrievable it is insecure and you (or your company) are being negligent by not following industry standard best practices. May 4, 2011 at 0:20
  • 1
    If you can login via the hash, the main purpose of hashing the password is immediately compromised. My answer stands. Don't do it. It's wrong. May 4, 2011 at 3:20
1

Considering current events (the Epsilon data leak and the Playstation Network data leak), one would hope the problems would be glaringly obvious.

Sometimes, however, as a developer you simply cannot affect policy.

I would do my best to show the potential for scandal and expense, which should be easy, again considering current events. But if that is unsuccessful, what can you really do. Not much. Quit in protest, demonstrate the vulnerability to raise attention. Neither sound like great options.

1

I'd advise against this, but if you absolutely must have the ability to decrypt passwords, you should use public key encryption. That way, you can encrypt all passwords using the public key. You can verify passwords by encrypting with the public key and comparing, and you can keep the private key somewhere else (not on the production computer).

2
  • 1
    Yes private keys should be on admin machines (behind firewall), or even better if they are on USB keys that only Admins have and personally use. But they shouldn't be allowed to take these keys home, because they could get stolen. May 4, 2011 at 6:00
  • Maybe stored in a password safe like KeePass. That way even if the computer is compromised, it's protected by the admin's password (hopefully a good one). I'd say on an encrypted USB key in a safe, but it sounds like they plan to use it frequently.. May 4, 2011 at 16:18
0

Usually the reason for an Administrator to see the user password is in case they lose it, they can give it to the user. As far as I can tell, Windows does not let the Administrator see the password either - so why should your application ? Any in house encryption library is sure to be broken because I am sure whoever wrote it does not work for the NSA.

1
  • Of course, you assume the Question Asker does not work for the NSA. May 4, 2011 at 2:09

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