Why does your API still use HTTP Basic Auth? • Hacker News Board

Re: Why does your API still use HTTP Basic Auth?

#111

Post by poutine » Thu, Apr 18, 2013, 5:17 PM UTC

Rygu wrote: post #107

poutine wrote: post #81

As an API and security professional I've found to be secure and performant one should do the following with APIs: - Dont listen on HTTP, force HTTPS (Tune your ciphers! see https://www.ssllabs.com/ssltest/index.html ) - Ensure that any client libraries you supply for API interaction must verify the server certificate - Only use the users password to obtain a long random key from the server either through an admin web…

Can you explain why one shouldn't use HMAC signatures to sign requests? How else can you guard against replay attacks, and authenticate the request? Only a key isn't enough, you need secrets as well. Right?

You're only using SSL which protects you vs relay attacks (it's doing its own MAC). Authentication is being done through the HTTP request Authorization header and the attached pre shared key.

Use SSL only, tune ciphers and you're good. You're wasting time trying to overthink the problem by adding another layer on top.

Re: Why does your API still use HTTP Basic Auth?

#112

Post by MichaelGG » Thu, Apr 18, 2013, 5:26 PM UTC

tptacek wrote: post #106

corresation wrote: post #94

Earlier quoted context omitted.

Doesn't exactly the same concerns arise? A single purpose may be a major purpose, such as "transfer monies between accounts", and aren't exactly the same concerns relevant between passwords and keys? If someone gets a list of unencrypted (or poorly encrypted) passwords, they have the rights of the user. If someone gets a list of unencrypted (or poorly encrypted) keys, they have the rights of the API caller. The conce…

You do not need to obfuscate your API keys if you're generating them properly.

Would you mind enlightening us? If you're using API keys over TLS+HTTP Basic Auth, storing the plain API key in your database means that anyone with readonly access to the API key table can now use those accounts. (Ignoring IP filtering or something.)

What am I missing?

Re: Why does your API still use HTTP Basic Auth?

#113

Post by tptacek » Thu, Apr 18, 2013, 5:26 PM UTC

poutine wrote: post #109

mechanical_fish wrote: post #105

Earlier quoted context omitted.

I will state the argument as I understand it: The difference is that you can, and should, rotate your API keys automatically and fairly frequently (I will leave it to experts to tell us how frequently is prudent.) Moreover, when you think your DB has been compromised you can flush all the API keys and reissue them. Depending on the application this may be more or less of a pain for the customers, but at least it is p…

In common usage the user will take an server generated API key and embed it within their application that makes API requests. Take a very typical example of a merchant selling snowboards and using Stripe to process the payments as an example. Since this API key is embedded within their app it'll require a programmer to change (and customers often may be non technical with sites built on contract). These are things yo…

If you lose the database containing either your API keys or hashes of your API keys, you need to revoke the keys. Not doing so is negligent.

The correct next step after discovering that you may have lost custody of API key information is to ensure that the keys are worthless, not to scramble to try to protect the keys.

This is another reason you want to be clear about the difference between a "key" and a "password", because passwords are sticky. A benefit of working with keys is that they are not; you can zorch a key with minimal provocation.

Re: Why does your API still use HTTP Basic Auth?

#114

Post by poutine » Thu, Apr 18, 2013, 5:29 PM UTC

poutine wrote: post #81

As an API and security professional I've found to be secure and performant one should do the following with APIs: - Dont listen on HTTP, force HTTPS (Tune your ciphers! see https://www.ssllabs.com/ssltest/index.html ) - Ensure that any client libraries you supply for API interaction must verify the server certificate - Only use the users password to obtain a long random key from the server either through an admin web…

I'm mentioning tuning your SSL ciphers a number of times in this thread. It really is quite important. For Nginx you should compile it with the latest OpenSSL (1.0.1e right now -- you can statically link it if you dont want to mess up your OS's packages) to get the latest ciphers.

Use a config line like the following in nginx:

ssl_ciphers ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH;

RC4 is a problem right now but unfortunately there's not a good solution until we get more TLS 1.2 support out there.

If you don't do this sort of tuning you're exposed to some weak ciphers that can result in attacks.

Re: Why does your API still use HTTP Basic Auth?

#115

Post by tptacek » Thu, Apr 18, 2013, 5:42 PM UTC

MichaelGG wrote: post #112

tptacek wrote: post #106

Earlier quoted context omitted.

You do not need to obfuscate your API keys if you're generating them properly.

Would you mind enlightening us? If you're using API keys over TLS+HTTP Basic Auth, storing the plain API key in your database means that anyone with readonly access to the API key table can now use those accounts. (Ignoring IP filtering or something.) What am I missing?

If an attacker gets access to the key table, you are boned. Revoke all your keys. Make the keys worthless; don't take half-measures to try to protect them.

Re: Why does your API still use HTTP Basic Auth?

#116

Post by acqq » Thu, Apr 18, 2013, 5:55 PM UTC

wisty wrote: post #100

acqq wrote: post #93

Earlier quoted context omitted.

Storing SHA in the database or anything not produced by PBKDF2, bcrypt or scrypt is wrong and doesn't help you much "minimizing damage." Advising SHA doesn't seem to come from a real professional.

SHA is OK, if you have a long random key. I forget the numbers, but a decent random key (100 chars?) becomes impossible to crack before the heat death of the universe. The exponential growth of the password space eventually defeats the weakness of SHA. The reason you need bcrypt is that user supplied passwords are crap, and can be cracked very quickly.

Yes, I agree that the length of the key and the real randomness are the most important points and that when those are fulfilled the recipe has sense. Neither explicit length minimality nor real randomness of the key were mentioned but the SHA advice was explicit to the 256 bits.

EDIT: To make it clearer: "Long" is not explicit. 256 bits is. The difference between real randomness and for example output of RND in your favourite language is also nowhere to be seen. Moreover the use of the "key" is dubious as it's not an encryption key at all.

Re: Why does your API still use HTTP Basic Auth?

#117

Post by nobodysfool » Thu, Apr 18, 2013, 6:09 PM UTC

poutine wrote: post #81

As an API and security professional I've found to be secure and performant one should do the following with APIs: - Dont listen on HTTP, force HTTPS (Tune your ciphers! see https://www.ssllabs.com/ssltest/index.html ) - Ensure that any client libraries you supply for API interaction must verify the server certificate - Only use the users password to obtain a long random key from the server either through an admin web…

This article just makes a big huff about nothing. go to http://api.stripe.com - what you get is immediately a redirect to https, and a 401 which requests the auth. It does not request http basic over http, it requests it over https. The issue is if you are a dumb developer, you might supply authentication over http, which would make that insecure. However, what I see it is requesting is an API key, which normally with payment providers, only allows making a charge, or refunding a charge, provided you know the charge ID. So your financial risk is very low even if someone knows your API key. They also usually recommend you change your API key at least once a month.

Re: Why does your API still use HTTP Basic Auth?

#118

Post by ryan-c » Thu, Apr 18, 2013, 6:16 PM UTC

poutine wrote: post #111

Rygu wrote: post #107

Earlier quoted context omitted.

Can you explain why one shouldn't use HMAC signatures to sign requests? How else can you guard against replay attacks, and authenticate the request? Only a key isn't enough, you need secrets as well. Right?

You're only using SSL which protects you vs relay attacks (it's doing its own MAC). Authentication is being done through the HTTP request Authorization header and the attached pre shared key. Use SSL only, tune ciphers and you're good. You're wasting time trying to overthink the problem by adding another layer on top.

The problem is that it is very common for SSL client libraries to neglect to validate the peer certificate...

Re: Why does your API still use HTTP Basic Auth?

#119

Post by mpyne » Thu, Apr 18, 2013, 6:27 PM UTC

acqq wrote: post #116

wisty wrote: post #100

Earlier quoted context omitted.

SHA is OK, if you have a long random key. I forget the numbers, but a decent random key (100 chars?) becomes impossible to crack before the heat death of the universe. The exponential growth of the password space eventually defeats the weakness of SHA. The reason you need bcrypt is that user supplied passwords are crap, and can be cracked very quickly.

Yes, I agree that the length of the key and the real randomness are the most important points and that when those are fulfilled the recipe has sense. Neither explicit length minimality nor real randomness of the key were mentioned but the SHA advice was explicit to the 256 bits. EDIT: To make it clearer: "Long" is not explicit. 256 bits is. The difference between real randomness and for example output of RND in your…

From the comment you initially replied to:

"Only use the users password to obtain a long random key" (emphasis mine).

So it was part of the initial recipe.

Re: Why does your API still use HTTP Basic Auth?

#120

Post by bgentry » Thu, Apr 18, 2013, 6:29 PM UTC

A great alternative if you can't (or don't want to) close port 80 is to return a 401 for non-HTTPS requests to your API, rather than redirecting with a 301 from HTTP->HTTPS.

This has the side effect of making sure that HTTP clients can never silently redirect, and it's impossible for a developer to ever get their code working without explicitly using SSL. If it never works in development, they'll never ship such code to production.