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

131–136 of 136 posts

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

#131

Post by cobralibre »

mnarayan01 wrote: post #71
rapala wrote: post #28

Earlier quoted context omitted.

By my reading, the spec is not that clear about it. It does say that A user agent that wishes to authenticate itself with an origin server--usually, but not necessarily, after receiving a 401 (Unauthorized) -- implying, imo, that no prior 401 response is needed. On the other hand, the spec also says A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the…

I don't think there's any ambiguity here...the first quote indicated that a client is absolutely allowed to send auth headers without receiving a 401 response. I read the second quote as giving client implementers a suggestion on when they should automatically send the auth headers, without actually requiring them to do so.

I agree, and the practice of sending an Authorization header without first receiving a challenge is common enough that there's a phrase for it: preemptive authentication.

See, for example, the Apache HttpClient documentation: http://hc.apache.org/httpclient-legacy/authentication.html#P...

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

#132

Post by e12e »

corresation wrote: post #51
tptacek wrote: post #47

Don't use the "signature" gem. Rails already provides a MessageVerifier class that wraps OpenSSL's HMAC; the "signature" wrapper uses "==" to compare HMAC values, and is thus timeable. Really, don't use HMAC-of-the password authentication tokens at all, though. They're not nearly as secure as TLS. Better still, don't use passwords in your API at all. Passwords are for humans. APIs use keys.

Better still, don't use passwords in your API at all. Passwords are for humans. APIs use keys. You make great points, but just as a point of clarification (because I saw numerous people confused by this yesterday), this is merely nomenclature, no? What you are calling a key is really a long, random password (in Amazon's case the secret Access key).

>> Better still, don't use passwords in your API at all. Passwords are for humans. APIs use keys.

> this is merely nomenclature, no? What you are calling a key is really a long, random password

Both passwords and keys are shared secrets. A password is a secret a human remembers, and can prove he/she remembers. A key is something a machine stores and can prove it has.

(Actually, an API key can also be a token, eg: "{ hash: " + hash(key+salt+date(now))+"valid from: " + date(now) + "salt: " + salt + "}" -- that is -- if you know the key, you can verify that that the token is indeed valid from the date claimed (and you could add serial numbers and other stuff as well). Note that the user doesn't need to know the key in this case, the user only needs a copy of the token).

So yes, it is nomenclature, but it matters.

[edit: formatting, typo]

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

#133

Post by poutine »

veesahni wrote: post #127
poutine wrote: post #88

Earlier quoted context omitted.

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.

Ah, that's fair I guess the trade-off is here that the api key cannot then be retrieved from a GUI either (because the server doesn't actually know the original key!) .. from a UX perspective, most companies show your active keys in a GUI with ability to selectively remove or replace. Though I can't think of a mainstream API that hasn't let me retrieve api key from GUI

Indeed, this is where common usage hasn't really caught up with best practice. It really is no better than showing the user their cleartext password.

Ideally you'd regenerate the key each time the user wants to show it or just use OAuth 2.0 (it's not as bad as everyone says it is).

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

#134

Post by mekoka »

psionski wrote: post #63
kbutler wrote: post #62

Earlier quoted context omitted.

tl;dr: Summarizing offends me

You see? When you put it that way it sounds stupid; otherwise it has beautiful words like "butchering" that convey additional feelings about the subject :)

tl;dr lossy compression

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

#135

Post by tszming »

If people can accidentally send plain text password to Stripe for a 403 response and don't care about it, I can't see why people can't accidentally send plain text password to the HMAC-SHA protected port 80.

They are the same thing, both will not work.

(Unless you close the port 80, using HMAC-SHA can't solve the issue.)

Post reply on HN