Securing an API: SSL & HTTP Basic Authentication vs Signature

Solution 1:

HTTP Basic Authentication over SSL is perfectly secure from my research.

After all, using SSL (strictly TLS now) means the transport layer is encrypted and we can safely assume any information passed over this is secure and has not been tampered with.

Therefore passing the username and password without generating a signature is sufficient.

Solution 2:

Igor's answer is not entirely true. Although TLS does ensure that the transport layer is encrypted and secure, it is still not as secure as using for instance TLS with mutual authentication where the client authenticates using "strong cryptography" in the form of a digital signature. There are two major reasons why this is still better than Basic Authentication over TLS:

• Passwords are passwords and I'd assume three out of the now 7 billion people on our planet use a 30 character password that is completely random. The rest of us chose something with a lot less entropy. Therefore it is much easier for an attacker to brute-force a service that uses passwords instead of digital signatures.

• One could argue that for client-side digital signatures there is also a password involved, for accessing the private key usually. But this is still a much different situation than the one we have with Basic Auth: first the private key resides as a resource on the client's machine so even if it is recovered it will only affect one person instead of everyone and second, for typical key container formats such as PKCS#12 there is also Password-Based Encryption used for accessing the key. These algorithms were specifically designed to slow attackers down to reduce their rate of brute-force attempts per unit of time, again an advantage for digital signatures.

There's no doubt that TLS Basic Auth is much more convenient to set up and use, but for high security environments I would always prefer "strong cryptography" over user/password solutions, it's worth the trouble.

Solution 3:

The Heartbleed issue with OpenSSL illustrates the potential pitfalls of relying solely on SSL for securing an API. Depending on the API's use and implications if the SSL transport were compromised, additional security measures may need to be taken as mentioned in Emboss's answer.

Solution 4:

It's ok to use a subdomain as username, as long as there's some form of a secret.

The benefit of using a shared secret, is that the 'party' doing the request does not need to know the secret, it only needs to know signature to perform the request. This is beneficial if you want your users to allow requests to be made through a browser, for instance.

Using S3 you are able to create a signature, send it to the browser and do direct uploads from a browser to S3.

You could also use HTTP Digest, which has benefits from both. You can still easily test the API in a browser, because browsers support Digest and Basic, and a plain-text password is never sent over the wire.