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.

RoboShop
  • 2,770
  • 6
  • 29
  • 38
  • 9
    "which they have said, they require". And they also lie. – S.Lott May 04 '11 at 01:06
  • 10
    Whatever you do, just cover your ass. – Job May 04 '11 at 01:23
  • Please provide the web address of this application, so we can *take a look at those accounts* ;) – Robert Koritnik May 04 '11 at 05:46
  • You could of course **log in as the stubborn boss that can't be convinced** about security threat and **do something overly stupid** just to prove him what could happen. Do something that will not hurt business but will act as an example of security and much harder way of tracking who did it. Try to do this from his computer if you can as well. So you can't be tracked down. Or from some admin's machine that thinks the same as that particular boss. – Robert Koritnik May 04 '11 at 06:07
  • 4
    @Robert Koritnik: Doing that can expose him to criminal liability in many jurisdictions if his company is dumb enough (the latter is quite likely given facts in his story) so it's not a very practical idea. – sharptooth May 04 '11 at 13:16
  • 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. – Berin Loritsch May 04 '11 at 16:31
  • 10
    Building the new PSN? ;-) – vartec May 04 '11 at 16:34
  • 11
    So tempting to retag this question with "Sony". – Joel Etherton May 04 '11 at 16:35
  • @sharptooth: I know you're right. Sometimes one thinks of extreme measures when approached with such a stupid upper management. I wouldn't do it myself either. But to convince this *boss* I might do it in front of him and try to logon to some site. Just for the proof of concept so he would be convinced. But smart person would stop being so stubborn when telling him all these facts. One answer was particularly interesting that talked about selling info. – Robert Koritnik May 04 '11 at 18:15
  • Are these passwords for those email accounts, or are you just using the email as a user name, and these are passwords for your app? (ignoring that a user might use the same for both) – GrandmasterB May 04 '11 at 18:24
  • Could you tell us which business this is, so we can either avoid it or use a special password for it? – David Thornley May 04 '11 at 20:53
  • 3
    This might be a bit out of your scope, but most governments have some pretty strict statutes about security for internal software/networks. Any way you can discreetly either look them up, or enlist the help of a policy-knowledgeable source? There may be some way to politely spin your case as "just complying with policy" or some such. – Beekguk May 04 '11 at 21:45
  • Depending on country there may be serious legal implications for their negligence. – Jack Aidley Feb 07 '17 at 09:50

14 Answers14

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.

Jaap
  • 2,295
  • 16
  • 21
  • 6
    +1 for the second paragraph and the "Not doing so is a bug". I wish every developer would understand that. – Arseni Mourzenko May 04 '11 at 00: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 04 '11 at 00: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. – Berin Loritsch May 04 '11 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 05 '11 at 05: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 03 '20 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.

Rein Henrichs
  • 13,112
  • 42
  • 66
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.

Robert Koritnik
  • 3,511
  • 1
  • 16
  • 26
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.

Kate Gregory
  • 17,465
  • 2
  • 50
  • 84
  • 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 04 '11 at 00: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 04 '11 at 00: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. – Kate Gregory May 04 '11 at 01: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. – Carson63000 May 04 '11 at 03: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.

dietbuddha
  • 8,677
  • 24
  • 36
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!).

Tangurena
  • 13,294
  • 4
  • 37
  • 65
  • 75 million accounts for the PlayStation Network, 25 million accounts for Sony Online Entertainment. I'm not sure I believe that there were only 12,000 credit cards exposed in this leak. http://www.wired.com/gamelife/2011/05/sony-online-entertainment-hack/ No evercrack until the weekend. Maybe. – Tangurena May 04 '11 at 19:55
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.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
Michael Brown
  • 21,684
  • 3
  • 46
  • 83
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.

Christopher Mahan
  • 3,404
  • 19
  • 22
  • +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 04 '11 at 00:50
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.

JeffO
  • 36,816
  • 2
  • 57
  • 124
  • 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 04 '11 at 00: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 04 '11 at 00: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 04 '11 at 00:13
  • "Security often suffers for convenience." Security is the *one* thing that MUST NOT be compromised for the sake of convenience. I know exactly what happens when you do that. You get hacked and your business is (nearly) ruined. I've been there. – Rein Henrichs May 04 '11 at 00:15
  • You're all correct really. It's needs to be fixed but it needs to be convenient. How about this? I hash the password, and the admins can see the hash and log in with it? – RoboShop May 04 '11 at 00:19
  • @Renesis, security can seem worthless until you're compromised. Then you know that it is priceless, but it's already too late. – Rein Henrichs May 04 '11 at 00:19
  • 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. – Rein Henrichs May 04 '11 at 00:20
  • @Rein : the password isn't retrievable, the hash value is, by the admins. It's a compromise, and in the best scenario, I would not reveal the password at all, but it compromises my site's security at the expense of protecting their password. – RoboShop May 04 '11 at 01:07
  • 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. – Rein Henrichs May 04 '11 at 03:20
  • @Rein : the main purpose of hashing the password is so you don't have to store the password anywhere. This doesn't violate that principle. Also, I could hash the hash value along with today's date so that it would kind of be like a token that only worked for today. – RoboShop May 04 '11 at 04:01
  • @RoboShop You seem determined to do the wrong thing. I've tried to convince you otherwise. I won't waste any more time. – Rein Henrichs May 04 '11 at 06:30
  • @Rein : Sorry you feel that way, but it's not that I'm "determined" to do the wrong thing, it's just that I have a number of other priorities - like the amount of time I have to spend on this, getting business approval on any functionality changes etc. In a number of ways my hands are tied. I'm only trying to find the least wrong thing. – RoboShop May 04 '11 at 07:00
  • @RoboShop - just thinking quickly over your proposed idea, I don't think you are understanding the purpose of the hash. The purpose is a one-way corruption that can be repeated later on test values. This way you can see if the stored value and the test value are the same without knowing what the original was, so that no *known* string can be used to log in. If you can log in as the hash, *it's the same as an unhashed password*. – Nicole May 04 '11 at 15:38
  • @Renesis - there is no indication that they won't allow the changes. They don't understand the need and appear to me to be driven by the loss of the current functionality. My solution addressed their major concern. You don't know if they will allow the password fix until you propose a solution that includes keeping the ability to login as a another user. – JeffO May 04 '11 at 20:56
  • @Jeff O : Thanks it's a sensible suggestion. Unfortunately, the business see this as non essential so they aren't willing to prioritise a lot of time for it. Building an impersonate function will more require more system wide changes, and DB changes if you want to capture the changes for audit purposes, and more testing. – RoboShop May 04 '11 at 23:19
  • @Renesis : Thanks for the comment. How about this? Instead of being able to log in with the hash, I'll allow them to generate a temporary token which will be like hash(today + passwordHash). They can use this token to log in to that user account for the day. I understand there are security implications to this too. If you know the passwordHash and my token algorithm, you can essentially do this yourself. But to tell you the truth, protecting their password is MUCH more essential than protecting the system. – RoboShop May 04 '11 at 23:54
  • @RoboShop - That essentially sounds like an impersonate. I can't tell you quickly how secure that solution sounds, but if protecting the system isn't actually all that vital then you might as well use a super password or something similar to your idea. – Nicole May 05 '11 at 00:14
  • @Renesis : Oh ok cool then. Yeah, maybe in a later release, I can talk to them about having some UI functionality and probably changing the Database to actually log these impersonates, but for now, I think it's an easy fix which fulfills the most important criteria. – RoboShop May 05 '11 at 00:40
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"

Phil Lello
  • 875
  • 6
  • 14
  • +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 04 '11 at 02:00
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.

Jerry Coffin
  • 44,385
  • 5
  • 89
  • 162
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.

quentin-starin
  • 5,800
  • 27
  • 26
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).

Brendan Long
  • 806
  • 8
  • 12
  • 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. – Robert Koritnik May 04 '11 at 06: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.. – Brendan Long May 04 '11 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.

Engineer2021
  • 3,238
  • 5
  • 28
  • 32