Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 10 down vote favorite
4

I am looking for a way to store a key used for password encryption. I am using a mysql db which would store a user name and an encrypted password that would be encrypted using AES_ENCRYPT(str,key_str). But where to store the key for password decryption to make it safe?

share|improve this question
1  
There really isn't a way to store it, at least not in a safe way, more information is needed to expand this comment. – Ramhound Mar 1 '12 at 17:28
1  
Without secure hardware, I think you are out of luck. That is why it is most common to store a hash of a password instead of an encrypted version of a password. If you have secure hardware such as a TPM, you could use that. – mikeazo Mar 1 '12 at 18:16
1  
Are you 100% sure hashing isn't an option? – David Schwartz Mar 2 '12 at 11:54
4  
Radek, welcome to IT Security. Important note, aside from the information in the answers below: Passwords should not be encrypted at all! There is really no good reason to decrypt the passwords in the first place. Instead you should be hashing them (thats kinda like one-way encryption), ideally with something strong like bcrypt. There are plenty of posts here, look through the passwords tag.... – AviD♦ Mar 8 '12 at 22:54

2 Answers

up vote 13 down vote accepted

There isn't a good answer. But here are your possibilities:

  1. Tie the encryption key to your admin login (e.g. encrypt the the encryption key with your admin login). This is only marginally useful as it requires you to be logged in in order to encrypt/decrypt anything. But on the plus side, no one can encrypt/decrypt anything unless you're logged in (i.e. greater control). Much of the secure storage in Windows works like this.

  2. Tie the encryption key to your hardware. TPM chips are useful for this, as are USB security tokens (not flash drives, though). In this case, crypto only works on that specific piece of hardware, but isn't otherwise restricted.

  3. Type in the encryption key when you start up, store it in memory. This protects against offline attacks (unless they capture the key out of RAM, which is tougher to do). Similar to option 1, but also different. However, the server boots into an unusuable state, requiring you to manually supply the key before work can be done.

  4. Store the key on a different server. E.g. put the key on the web server and the encrypted data on the database server. This protects you to some degree because someone would have to know to grab the key as well as the database, and they'd also have to have access to both servers. Not amazingly secure, but an extremely popular option anyway. Most people who think they're doing it right do it this way.

  5. Store the key elsewhere on the same server. This is a particularly popular option for people who only have one server. Adds marginal security, but not a whole lot. This is what most people do.

  6. Store the key in the database. Now you're hardly even trying. Still, a very popular option.

share|improve this answer
up vote 0 down vote

I realize this was answered a while ago, but to give a couple examples to Tyler's good answer: I plan to use his #1 to tie a password to a service account and use a Powershell cmdlet to grab it. That way the scripts do not need to be as heavily modified. The service account's password is in Active Directory and would have to be compromised first. This works for me since I have use it on two servers. For his #4, to meet our compliance we were able to store a key in plain text on another server with external storage because that storage was itself encrypted and access to it restricted. As Tyler mentions the latter doesn't seem so secure, but it was good enough even for a tough assessor.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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