4 ms·

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

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 hashing passwords in your DB, you should be using a slow hash like bcrypt. That means a single request that might take 30ms now takes perhaps 500ms. And many workloads are going to require multiple hits to the API to accomplish simple tasks, so your talking about both a strain on the system, and a horrible experience from the client's perspective.

wickedshimmy 14y ago
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 and a request fails authentication, the client simply requests a new one and retries. The token lifetime is a much easier adjustment for which to weigh security versus performance/load considerations, compared to against broader password storage security.
- poutine 14y ago
  You've described OAuth in part with its refresh and access tokens.
poutine 14y ago
This isn't a problem specifically with HTTP basic which at the end of the day is just a HTTP request header with an encoded string. If you're using basic auth and a long random server generated key as Stripe does instead of a user supplied pasword performance is a non issue as you'd SHA2 it in your DB not bcrypt.

wickedshimmy 14y ago

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 and a request fails authentication, the client simply requests a new one and retries. The token lifetime is a much easier adjustment for which to weigh security versus performance/load considerations, compared to against broader password storage security.

poutine 14y ago
You've described OAuth in part with its refresh and access tokens.

poutine 14y ago

This isn't a problem specifically with HTTP basic which at the end of the day is just a HTTP request header with an encoded string. If you're using basic auth and a long random server generated key as Stripe does instead of a user supplied pasword performance is a non issue as you'd SHA2 it in your DB not bcrypt.