I want to host a PHP application on a shared, remote server where I have only ftp access. I have to assume such a server is not secure, since any sysadmin at the hosting service can browse at will. I’m surely not the first person to host an S3 application on a remote server, yet there are only unanswered threads in the AWS forums regarding best security practices. So I’m guessing that some users are uploading the AWS secret keys and hoping for the best.

Here are the ways I’ve considered for using S3 from a Shared, Remote Web server:

1. Upload Secret Key – either in plain text or nominally concealed by an XOR hash or hex encoding. It would be concealment only, not encryption, since PHP is not compiled.
2. Encrypt and Upload – use another language (Java) or extension (Zend engine) that provides some security. AWS has some sample Java code that does this.
3. Use Public Buckets – from a secure machine, create a public_read_write bucket on S3. The PHP application on the shared server can then use anonymous access to read and write objects without requiring the secret key.
4. User Grantee – the AWS documentation states that access can be granted to anyone who has an account on amazon.com, even those without an AWS account. Obviously, such a person would not have a secret key. So the shared server application could use an amazon account to access a bucket with such a grant. However, the documentation does not explain how to sign a request with a canonical account name without a secret key.

I rejected options 2 & 4 as having too many unknowns at this stage of development. Adding a new language just to encrypt a key is a big hit in complexity. Similarly, with no cookbook example and the rather hastily assembled user documentation, I expect lots of trial and error for option 4. But once documented, option 4 would be my clear first choice.

Options 1 & 3 shift risk between a particular bucket and one’s secret key. With option 3, anyone who discovers the publicly read/writable bucket can use it immediately without even needing to find my PHP source code. But since they don’t have my secret key, I still have control over the bucket and can turn it off (delete it or make it private).

Option 1 exposes no public buckets on the web. But the worst case (someone gaining access to the remote server and stealing the secret key) has a big exposure. Only Amazon customer service can turn off a secret key, and they’re available only by email and only during business hours. If they take a week to shut off the key, I’d be liable for all of the charges.

My choice is option 3. I’m more comfortable with the risk profile being concentrated onto one bucket. Also, option 4 is a straighforward upgrade once more documentation becomes available. One unknown: is there any easy way for hackers to scan AWS S3 searching for public buckets? Let’s hope not.

• Test Utility for Amazon S3 in PHP – from the AWS Developer Connection, it provides s3-test-utility-php.zip which contains: s3.php, index.php, and readme.html. Using the browser GUI provided by index.php to control s3.php, I was able to create a bucket and upload an object. Code is documented and lists the derivation history of the code (see Storage3 and Mission Data Blog below).
• Amazon S3 Sample in PHP – an alternative s3.php that has some common heritage with the Test Utility s3.php.
• Storage3 Project – the predecessor of the AWS Test Utility package, provides file Storage3.php plus the required PEAR modules (making it easy to install on a remote server where PEAR can’t be invoked).
• Mission Data Blog – presents the original putObjectStream() method that has now been modified to use a file in the AWS Test Utility.

I want to stream data directly to S3 (without first saving to a file) thus the current form of the AWS Test Utility package won’t work directly. I can either use the Storage3 project or substitute the Mission Data putObjectStream() method back into the AWS Test Utility s3 class.