What are your suggestions for storing AWS authentication data?

Question

Scenario: a web application written in PHP utilizes an Amazon Web Service and must keep the Access Key ID and a Secret Access Key handy in order to function. Are there current recommendations and/or API's out there for storing this data securely?

My thought is to symmetrically encrypt it into a file based on a key created from local server variables. That way it's [hopefully] gibberish if someone gets a copy of the file through FTP, lost laptop with files copied, etc. The concern I have is that a skilled attacker could just upload their own script to decrypt it.

This seems like a common situation and one I've never achieved a comfortable solution for. Obviously I can't use a one-way hash, because I need the original data to create a HMAC to send to AWS. Links to related S.O. questions are very welcome.

Answer 1

Ah. The question of security.

I think the question you should be asking here is what do you do with say, for example mySQL passwords in your php config files?

To be quite frank, I would say that if someone managed to get a copy of your files, then your security needs rethinking anyway. For my own use, I generally only keep the passwords in one place, (on the server where they should be used) and make sure that I use a randomly generated password each time (paste it into the config file, and voila!)

To be honest, if it's not your own host, ANY sensitive data can be compromised.

If it is your own host, I'd suggest using proper permissions within Linux, and PHPSuExec to make sure that only the scripts that YOU write can access the files.

Anyway, to answer your original question, your AWS Access / Secret Keys are just the same as a MySQL password, Ok, it has the potential to let someone access your service, but it doesn't give them access to your personal details. Even with symetric encryption, if your script has a security hole, the information can be accessed.

Put simply, you take a risk when you put these keys anywhere that is accessible to anyone but you. How much do you trust Amazon's servers not to be compromised?

My suggestion would be to try and add as much security as you can, but keep an eye on your account, I'll generally have a cron job running to send me an email with changes to my S3 account (new files uploaded, new buckets etc etc) and from that I can tell what's going on.

There is no easy solution, it's a mix of securing each seperate layer of the System. I mean, if you use symetric encryption, the password for that has to be stored somewhere, right? or are you going to type it in every time ?

Hope this helps

Answer 2

My thought is to symmetrically encrypt it into a file based on a key created from local server variables. That way it's [hopefully] gibberish if someone gets a copy of the file through FTP, lost laptop with files copied, etc. The concern I have is that a skilled attacker could just upload their own script to decrypt it.

This wouldn't hurt, but ultimately it is just security through obscurity as somebody who can read the file can probably also read and reverse engineer your code. Short of typing in a password or otherwise providing a secret every time the server starts, encryption isn't going to help. It just shifts the problem to how will you protect the encryption key (which also needs to be accessible to the server)?

You have to harden and design your application and server (don't forget the OS, and remote access to the OS) so that nobody unauthorised can read the files on the system in the first place.

If you're worried about someone getting physical access to the box, concentrate on physical security to stop that happening.

Answer 3

I use symmetric encryption like you suggest. When I start my server I need to give it a key to decrypt the files containing the authentication data.

Of course a hacker could do a memory dump and read the password that way but that's quite a bit tougher than reading a cleartext file. There's no perfect solution, security is always a compromise between risk and ease of use.

So server security is still the key issue, its just a question of how much security is enough. I'd suggest looking at Bastille Linux or something like that to harden your server but that's another topic altogether.