views:

85

answers:

3

I have an application where I need to store 3rd party credentials to services like Amazon S3, FTP, SFTP, etc..

I know that it is possible to access some of those systems without passwords, but that has its own issues. If our customers gave us access to their S3 buckets via ACL we would still need to verify which bucket belongs to which user, same goes for SFTP and ssh key auth.

We will try our best to allow non-password alternatives where possible, but sometimes (FTP) it just won't be possible. Therefor I am looking for advice on how to store this sensitive data in our database (MySql) or elsewhere.

In the past I have read about people using TrueCrypt partitions that automatically unmount, but that would probably require decent intrusion detection. For now I'm interested in simple approaches that lead to reasonable security and can improved upon in the future.

Any advice on the subject would be highly appriciated!

+1  A: 

There are a range variety of possibilities and since in my opinion you provide not enough info about the context, i will try to give you an overview from my point of view. I assume that here the most important aspect is confidentiality of your data and and authentication of the users. Integrity and availability of data is much less important.

If you want basic security, you can let MySQL handle it by means of username/password combinations and set access rights on the given account. However, since the access control mechanism of mysql is not fine-grained (you can set access control rules per table only, not per row) this will probably yield a bad database design.

If you want to have a non-password approach, you can give users client-certificates and let them prove their identity by presenting their client certificates (use TLS for that) or let them sign something (note their are dangers because you create a so called signing oracle).

Another approach is to encrypt your data in the database. You can do that by deriving a symmetric key from the password and encrypt the credentials with this data. The catch here is of course that your key derivation protocol should be good and this is not easy to accomplish (so if you choose this, i advice you to take existing key derivation protocols or use a streamcipher). Take a look here for a list of streamcipher http://en.wikipedia.org/wiki/Stream%5Fcipher .

If you care very much for security you can start thinking about fancy solutions like authentication with smartcards, or a time synchronized tamper resistant device for generating acccess codes. However, note that these fancy solutions do not give you free security, implementing such systems if hard and costly (due to development and deployment) however, if done correctly they provide the best security.

Henri
A: 

Have the user supply a (strong) password when they set up an account (before they provide their passwords). Then encrypt all data for that account within your database using a key derived from a strong hash (SHA256 or something like that) of the user's password. That way if your servers get compromised, no data will be revealed because it is encrypted with the user's password (well, a hash of the user's password) and that password is not stored anywhere on your server.

jeffsix
If you do this, be careful of password changes: when the user changes their password (either because they forgot it and when through an automated change script, or forgot it and talked to a person, or because it's been 30 days, or whatever) you'll need to update the derived key and the encrypted data.
atk
Also keep in mind that emailing a password during a password reset is going give the key away. Generating a new password will make all the previous data useless.
Noah Campbell
-1 Storing the hash is just as bad as storing the password in this case. If an attacker gains access to the hash he can simply derive the key and use that to decrypt the account data.
Theran
You don't store the hash. When access is called for, the user supplies their password which is then used to compute the hash which is used as the key. Then the key is used to decrypt the credentials that are stored in the database and everything that has anything to do with the key is cleared from memory. You should never store the hash if the hash as keying material.
jeffsix
A: 

You need to investigate the use of keystores. TruCrypt is an example of such a keystore, but this is a personal keystore, not intended for service level credentials.

You won't be able to avoid storing their passwords in a format that someone can get access to, the goal is to minimize who can access the information. Putting in the same MySQL as application data is asking for disaster.

Noah Campbell