2

Short version

My boss wants me to store user passwords for an ASP.NET Web Forms web app we're developing in clear text, so that a user with admin rights can click a button and get back the current passwords for the accounts she controls.

I don't want to do that, because I deeply care about the security and privacy of users of a web app I am involved with in whatever way.

What would be a good way to store the passwords in an encrypted form, that can still however be decrypted?

I can't count on users having an email address, so sending the user a link to reset the password is not an option.

Read the following for more context.

Some context

This app was written by individuals who have little clue as to how software should be written. Lots of duplicated code, risks for SQL injection everywhere, no unit tests whatsoever, one new connection gets instantiated and opened for each and every query... name a bad practice, you'll find it in this codebase.

The passwords are currently stored as a simple MD5 of the original string, which is weak and horrible and everything, but still a tiny bit better than clear text.

I just finished implementing a feature request where the admin I was talking about can click a button and have an account automatically created for each employee she manages, with a random password. I cringe while writing this, but one of the requirements was to export the credentials in an Excel spreadsheet. Which I did.

This is bad in and of itself, but then my boss said "What if the user loses the spreadsheet? Users are dumb, you know. There needs to be a way to get the passwords back."

Bang.

Getting him to listen to people who know what they're talking about is not an option, sadly.

The obvious suggestion would be "GTFO", I know, but rest assured that it's something I'll do as soon as I possibly can.

Meanwhile, I need to cheat and pretend I store passwords in clear text, while I do things in the best way possible to protect my users' passwords.

EDIT

For some reason people answering are assuming I'm a girl so, just for the record, I would like to clarify that I'm a guy. Not that it should make any difference, but hey ;)

  • 1
    backup the spreadsheet in the database for later retrieval and continue as normal? – tom Feb 12 '14 at 16:57
  • 1
    MD5 is much better then storing passwords in clear text. It may be a weak hash but thats a lot better than clear text. Have you tried suggesting a password recovery mechanism? – m4tt1mus Feb 12 '14 at 17:22
  • 1
    I think you should explain why this is wrong. – Salih Erikci Feb 12 '14 at 18:01
  • 1
    @s.m I don't think the lack of an email address would prevent you having a "reset password" feature. The reset button would be in the admin console, and it would show the admin the new password (or put it into a spreadsheet as per a new user). Obviously this is still bad, but it would at least allow you to properly one-way-hash the passwords. – just me Feb 12 '14 at 19:02
  • 1
    @s.m just because they don't have an email doesn't mean you can't create security questions, text message, calling and admin to reset it, or some other mechanism for password recovery. – m4tt1mus Feb 14 '14 at 21:08
5

If you must do this because you aren't being given an option, you might encrypt the passwords with a password that is not stored in the code or in the database. Make the recovery 'by request' of the customer (they have to call you for it), and someone on your end would have to enter the password to re-generate the user/pass list.

Don't fret over the stupidity. You pointed out the more secure procedures, your boss ignored them. It probably wouldn't hurt to get your objections in writing (email) in case there's a problem and they try to blame you.

  • Solid advice, though it doesn't fit with "Meanwhile, I need to cheat and pretend I store passwords in clear text, while I do things in the best way possible to protect my users' passwords." I think the idea was to add security in a way that was transparent to her boss. – MetaFight Feb 12 '14 at 17:06
  • 3
    If it has to be completely transparent, its probably going to have to be some manner of obfusction of the password. I don't think there's a 'good' option here, just 'least bad'. – GrandmasterB Feb 12 '14 at 17:18
  • that's not necessarily true. The only thing required for this to be transparent is for no human interaction to be necessary. – MetaFight Feb 12 '14 at 18:04
  • First of all, thank you for your answer. Yours is a sound suggestion, in fact I did consider it for a while, but there was another requirement (which I admittedly forgot to mention): generate as few customer calls as possible. If my boss would discover that customers are calling because I didn't implement his obvious clear text solution I might have a tough time. A part of me just says "Fuck it, do what he wants and let customers sue him somewhere down the road", but the other part would feel horrible going down that route. – s.m Feb 12 '14 at 18:26
  • It sounds like there would be a manager who oversees a number of users, so you might give them the master password for their group of users instead. The one thing you have going for you here is it sounds like the passwords are randomly generated, so even if there is an exploit, learning those passwords may not help someone hack other accounts the user might have. – GrandmasterB Feb 12 '14 at 18:52
2

Store them in a file, and encrypt it with a key linked to the logged in user's account. Windows then manages the encryption and the security of being allowed to decrypt the file.

This way the password will always be in clear text... if you've logged on as the user that's allowed to read that file. You may need to truecrypt the entire drive to be totally secure, but a quick code app can do this (see 'protected configuration' for examples of securing app.config files - similar code could be used here, I assume) but code-based solution would not allow you to see the contents in an external viewer (eg excel), but you could easily store the file encrypted and give them a special viewer app "for security" so only the admin can see them in the clear. I figure that is what the real requirement is - not that they can use Excel, but they can see the passwords.

  • Correct, I mentioned Excel just to provide some context about how ridiculous the situation already is. I will look into your suggestion, even if I'm not sure it's worth the trouble. – s.m Feb 12 '14 at 18:28
2

risks for SQL injection everywhere

That's your chance. Exploit this and show your boss, how easy it is for any stranger to read the whole database, including your boss's password. Then ask him, on how many web sites he personally uses the same password. After he answered this, it's time to explain, what salted hashes in your web app can do for his PayPal account.

Especially given this cheesy software, where locating (let alone fixing) all the security holes will take a long time, a hashed irreversible pwd gives a big amount of security NOW, today.

BTW, could the SQL injection issues also be used to overwrite stored passwords? I'm just asking ...

-1

If you're dead set on being able to recover "the" password, I'd be tempted to try and give your users a tiny amount of security by hashing the passwords in such a way as to make it trivial to create a password that hashes to the same value without necessarily being the same password. (Remember, a high percentage of your users will be using the same password for their banks, credit cards, and retirement accounts!!!) This way, you can print out for your boss a password that will allow access to the account, without necessarily being identical to the user's password. If you construct a 60-bit hash carefully (outlined below), you can reverse the hash for all passwords shorter than 10 characters. Longer passwords will result in a false reversal... a password alias that creates a hash collision with the real password.

If you use a 60-bit hash, the probability of a collision is about 1 in a sextillion. Put another way, if an attacker is allowed 1 billion login attempts per second, it will take her on average about 17 years to log in if the user uses a strong password.

One possible implementation is to create a generalized feedback shift register of 9 base94 digits. pow(94,9) is just shy of pow(2, 60). The characters can just be read out of the feedback register. However, if the password is longer than 9 characters, the feedback will start mixing entropy of earlier characters back into the later characters, so longer passwords will be aliased by shorter passwords.

If you're supporting Unicode passwords, pick a normalization, normalize, and convert to UTF-8 before hashing. All passwords containing non-English characters will be aliased to English character passwords.

I wrote a short 100-line C program that implements the above and demonstrates its reversibility. The program takes a 20-character base64 obfuscation key followed by the password. It hashes the password and prints the hash and the backed-out password from the hash to stdout. It can be found at https://github.com/kmag/bad_password_hash

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

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