API Security: Basic SSL and HTTP Authentication and Signature

Question

When developing the API for our web application, we will use their subdomain as the "username" and generate the API key / shared secret. First, is it possible to use a subdomain as a username? I do not see the benefits of generating another key.

The various APIs seem to do one of two things:

• Use Basic HTTP Authentication with SSL

In each request, the username is set to a subdomain and the password for the API key. Since we use SSL, it should be safe from spoofing.

Known APIs: Google Checkout , Freshbooks , GitHub , Zendesk

2. Create request secret with shared secret

This is usually achieved by streamlining key / value pairs and using HMAC-SHA1 with a shared secret to generate a signature. Then the signature is sent with a request and verified at the other end.

Known APIs: Google Checkout , Amazon AWS

PS: this is not a mistake, Google Checkout supports both

Edit: Just read that OAuth 2 drops signatures in favor of sending username / password over SSL.

Any opinions from anyone about what to choose: SSL vs Signature?

Answer 1

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

In the end, the use of SSL (strictly TLS now) means that the transport layer is encrypted, and we can safely assume that any information transmitted through it is secure and has not been changed.

Therefore, it is enough to skip the username and password without generating a signature.

Answer 2

Igor’s answer is not quite right. Although TLS ensures that the transport layer is encrypted and secure, it is still not as secure as using, for example, TLS with mutual authentication, when the client authenticates using “strong cryptography” as a digital signature. There are two main reasons why this is even better than Basic Authentication over TLS:

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

• It can be argued that for digital signatures on the client side, a password is also used to access the private key. But this is still a completely different situation than the one we have with Basic Auth: first, the private key is located as a resource on the client machine, so even if it is restored, it will affect only one person, not all, but Second, for a typical key in container formats such as PKCS # 12, password-based encryption is also used to access the key. These algorithms have been specifically designed to slow down the attack of malefactors in order to reduce the speed of brute force attempts per unit time, which again is an advantage for digital signatures.

There is no doubt that TLS Basic Auth is much more convenient to configure and use, but for environments with a high degree of security I always prefer "strong cryptography" over solutions for users and passwords, this is worth the problem.

Answer 3

It’s good to use the subdomain as the username if there is some form of privacy.

The advantage of using a shared secret is that the "party" executing the request does not need to know this secret, it only needs to know the signature to execute the request. This is useful if you want your users to be allowed to make requests through a browser, for example.

Using S3, you can create a signature, send it to the browser and directly download from the browser to S3.

You can also use HTTP Digest, which has advantages from both. You can still easily test the API in the browser, as browsers support Digest and Basic, and the plaintext password is never sent over the cable.

Answer 4

The Heartbleed issue with OpenSSL illustrates the potential of relying solely on SSL for API protection. Depending on the use of the API and the consequences, if the SSL transport has been compromised, additional security measures may be required, as indicated in the Emboss answer.

Answer 5

Answering an old thread as no one touched the main point

SSL / TLS is fundamentally flawed , like all PKIs, because they rely on a trust chain that has been proven more and more vulnerable to the MiM attack :

• Certification bodies have been and can be hacked. One example among many is the DigiNotar case where the CA was compromised several months before the violation was recognized that all certificates were revoked. Meanwhile, the Iranian government has forged good full SSL certificates for google.com, facebook.com, twitter.com, etc.

• Company proxy filtering tools, such as Zscaler, that decrypt and re-encrypt all traffic on the fly for unspecified "security purposes." See this question / answer on SO

• Errors with the most common SSL implementation (openSSL) are detected all the time (but should things get better over time?)

Therefore, big players do not like to rely only on SSL:

In these cases, the HMAC token does not give you privacy, but it does not allow anyone who is following you to fake requests with your credentials , which would be otherwise trivial if you simply passed them through basic auth.

An alternative to the PKI model is the Trust Network , which does not rely on a single authority for certificate authentication, but rather on the opinion provided by the majority - well-known and trusted peers OR - known, but not necessarily trusted peers

This model is not yet perfect, because it is subject to the notorious 51% attack in the same way as for the bitcoin block chain (i.e. an example of a distributed trusted model)

Answer 6

I would like to point out some things mentioned in security.stackexchange.com, as you say: "Basic HTTP authentication over SSL is perfectly protected from my research." You can argue that points 3 and 4 below are rarely valid for the REST API, but it really depends on how they are implemented.

"There are several issues with HTTP Basic Auth:

• The password is sent via base64 encoded cable (which can be easily converted to plain text).
• The password is resent for each request. (Large window attack)
• The password is cached by the web browser, at least for the window / process length. (Another server request, for example. CSRF, can be reused.)
• The password can be stored permanently in the browser if the user
  Requests (The same as the previous paragraph, in addition, can be stolen by another user on a shared machine).

Of these, using SSL only permits the former. And even so, SSL protects only as long as the web server - any internal routing, server registration, etc. Will not see the plaintext password.

So, how important it is to look at the whole picture with something. Does the password protect HTTPS with a password? - Yes.

This is enough? Usually not. (I mean, always not, but it really depends on what your site is and how secure it should be.)