Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why does your API still use HTTP Basic Auth?

swaggadocio.com

Post reply on HN
Print view View original

81–90 of 136 posts

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

#81

Post by poutine »

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 interface where possible or by an API request that supplies the username and password and receives the key.

- Make authenticated requests of the API with the key

- Store any passwords as bcrypt hash in the DB for security

- Only store the key as SHA2-256 hash in your DB for performance

- Actually yes do use HTTP Basic as it's a convenient way to transmit the key (see how Stripe does it) making things easy for your users and perfectly secure as long as you prohibit plain HTTP.

- Stay the heck away from HMAC's and signing requests, you have SSL, properly tuned it's secure. HMAC is pointless here and really confuses the users.

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

#82

Post by poutine »

Joeri wrote: post #77
mechanical_fish wrote: post #64

Earlier quoted context omitted.

Nomenclature is important. As the joke says, naming things is one of the only two difficult problems in computing. [1] A good password is a long string of random characters, and an API key is a long string of random characters, but they are not the same because the semantics are different. Passwords are typically chosen by customers, changed (let's be honest) very rarely and on a haphazard schedule, often reused acro…

Arbitrary distinction. A password can be expired and forced to comply with complexity rules. A key is a server-side generated password, and therefore offers less ability for users to implement their own password policies. Good for users that don't care, bad for users that do care.

This is not arbitrary at all and has definition by industry standards. Passwords are used by people. Keys by machines. This requires different security policies. Passwords will have complexity rules and shorter expiration policies such as 90 days. Keys should have rollover policies around a year or so.

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

#83

Post by veesahni »

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…

Users should use "a long random key"

But you should store "the key as SHA2-256 hash in your DB"

why hash it?

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

#84

Post by poutine »

wickedshimmy wrote: post #78
crazydoggers wrote: post #65

I get the feeling that most people commenting here haven't actually implemented an API that is under heavy use and has strict security requirements. One of the main problems with Basic Auth that the author fails to mention is that if your passing passwords with every request, you're also hashing that password with EVERY request (assuming your doing REST, ie no client state on the server). And if you're properly hashi…

This is a very good point, and is the sort of situation where API tokens can come into play and be useful. A client can make a single request to "open a session" and receive a short-lived key that is used as the password credentials for subsequent requests. Store active keys - since they are short-lived, offline attacks are less of a concern and you can probably choose to not slow-hash them. When the token expires an…

You've described OAuth in part with its refresh and access tokens.

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

#85

Post by film42 »

I tend to use an api_key, because it's easier to manage. I'll setup a route to authenticate, where I'll use basic auth to return an api_key, and the remainder of the api either requires an api_key or no authentication at all.

For Rails developers, Ryan Bates does a great job of explaining a few ways to secure your api.

http://railscasts.com/episodes/352-securing-an-api

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

#87

Post by poutine »

rplnt wrote: post #18

Because I need the user's password in plaintext for example.

You should almost never know a users plaintext password. Outside of a small set of scenarios you're likely doing something very wrong if you need a users plaintext passwords. Passwords should almost always be bcrypt'd.

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

#88

Post by poutine »

veesahni wrote: post #83
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…

Users should use "a long random key" But you should store "the key as SHA2-256 hash in your DB" why hash it?

Because if someone gets access to your database somehow you're not exposing all of the keys for all of your users.

While you're likely in serious trouble if someone gets your DB this helps minimize damage. Besides to authenticate a request you dont need the plaintext of the key, a hash is fine.

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

#89

Post by tomjen3 »

patio11 wrote: post #20

This would be improved by a recognition that security involves trade offs, particular when you have existing apps in production that you don't want to break compatibility with. That isn't a laughable consideration: "A security problem in customer's code? Fire them as a customer!" Would indeed be effective at reducing their exposure but is not in their interests and has certain drawbacks with regards to one's odds of…

I don't think this is something you can mitigate with libraries, especially not as you need client libraries for a dozen or so languages and I (at least) wouldn't be willing to install software just to try out some service -- you pointed out in your blog how much users dread installing software, in my mind client libraries are even worse as you have to install them and their dependencies (which may or may not conflict with your own) which may involve more or less crappy tools (e.g. my JRuby build now depends on maven, because I need to use your client libraries) before you can even test the service.

So just use HTTPS and leave it at that.

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

#90

Post by tomjen3 »

sgt wrote: post #31
hrrsn wrote: post #21

Earlier quoted context omitted.

I agree, things like Oauth are also massively overkill for what should be simple jobs. The other day I was writing a script for my own personal use that needed to get some metadata from Imgur. Their API /requires/ OAuth, when even a json snippet for a public picture would have been just fine. Ended up just scraping the page as it was a one off script and was much faster than signing up, creating an application, imple…

You can use a subset of OAuth - I tend to use the so called "0-leg" version of OAuth, which is pretty much the same as a username/password (consumer key + secret), but with added benefits such as protection against replay attacks. It's also pretty simple to implement on client side and server side. I usually give our clients a little library to get started with requests.

Honestly there is nothing simple about OAuth -- and the specs are horrible (even when you understand them).
Post reply on HN