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

51–60 of 136 posts

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

#51

Post by corresation »

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).

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

#52

Post by [deleted] »

fiorix wrote: post #43
laumars wrote: post #36

Earlier quoted context omitted.

The title is a little misleading as the author is talking about HTTP vs HTTPS rather than the HTTP auth specification vs oauth (et al). Essentially his whole blog post could be reduced to this: servers shouldn't open port 80 on auth API sub-domains. While he does have a point, I do think part of the blame lies with the client side as well. If you're dumb enough to transmit user details over clear text protocols then…

hmm, not really... the post ends with: P.S. Don’t use HTTP Basic. Thanks. That just don't make any sense to me and implicitly suggests using other authentication methods.

[deleted]

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

#53

Post by mdellabitta »

sjtgraham wrote: post #50
scjody wrote: post #44

There's a very good reason for using HTTP basic auth: if you want to store password hashes on your server using a modern scheme like bcrypt or PBKDF2, you can't use digest authentication. The author suggests rolling your own authentication scheme based on HMAC-SHA, but then all the clients need to implement this scheme whereas HTTP basic auth is already part of most HTTP libraries. And do you really trust yourself to…

I did not suggest "rolling your own crypto". HMAC is detailed in an RFC ( http://tools.ietf.org/html/rfc2104 ), is widely used, e.g. Amazon AWS, and is part of OpenSSL. At no point do you have to "roll your own". If you don't implement this correctly the request will simply fail, the credentials won't be exposed at any point. Please spare me the FUD.

You are suggesting 'roll your own auth,' though. Which is more difficult to get right than most people think.

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

#54

Post by eddieroger »

zikzikzik wrote: post #39
xyproto wrote: post #29

Too much focus on closing port 80. They could just host something else on port 80.

No, the whole problem is a http server (ANY http server, serving ANY content) listening on port 80. Once the tcp connection is accepted on port 80, "dumb" clients (like curl) can just come barging through the door shouting plaintext auth credentials without knocking first, and no http server can stop them from doing that (because that is how the http protocol works). The only way to stop them from doing that is rejec…

The author made this seem outlandish, but really it's a reasonable and easily done way to go about things. Just have a special subdomain for your API (I don't know, api.*.com) and only listen on 443 with it. Done.

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

#55

Post by martin-adams »

If we're worried about a man-in-the-middle attack sniffing insecure credential on port 80. If the host closed port 80, couldn't the man in the middle just open it up again, you know, in the middle?

Maybe one recommendation should be supported vendor supplied SDKs which don't touch HTTP, only HTTPS. Another option is to detect credentials being sent over HTTP and notifying the clients, maybe deactivating their key if action isn't taken in a period of time.

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

#56

Post by acqq »

What's always needed is simply properly used TLS (https). Even wording in the article is misleading. It's not about "closing port 80" but about "using only TLS."

Once you use TLS is the "HTTP basic" often the optimal solution. After reading the whole article, I still don't understand why would anybody try to make HTTP "secure" instead of simply using TLS. So my question to the author, paraphrasing the article title:

Why the hell simply not using TLS and thereby avoiding the "basic auth is bad" misdirection?

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

#57

Post by Millennium »

rplnt wrote: post #18

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

If you need the user's password in plaintext (or something easily derived from it), then your authentication scheme shouldn't send it over the network at all: there are better ways to handle that scenario.

Also keep in mind that a machine storing plaintext passwords has the same security requirements as a Kerberos KDC, and those requirements are very, very high. Don't do this unless you know what you're doing, and even if you do, you should seriously consider a different scheme (or just using Kerberos itself: they've already gotten things right, so you don't have to risk getting things wrong).

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

#58

Post by Millennium »

xyproto wrote: post #29

Too much focus on closing port 80. They could just host something else on port 80.

That's not enough. The problem is that a client which mistakenly sends a request to Port 80 will send the Authentication request, which, as has already been established, includes (basically) cleartext credentials. Even if whatever you're hosting on Port 80 returns an error, the damage is already done. To prevent that, you have to abort the connection before the client even has a chance to send the request, i.e. closing Port 80.

This means that if you're going to use HTTP Basic authentication, you need to serve your API and your Website from different hosts.

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

#59

Post by anuraj »

Basic Auth should be used only with HTTPS/SSL - who does otherwise? Do not think HTTP Basic is a bad design choice with SSL for securing your service. Any security is brittle if you don't understand what you are upto. That said key based authentication is more apt for APIs.

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

#60

Post by bobwaycott »

anuraj wrote: post #59

Basic Auth should be used only with HTTPS/SSL - who does otherwise? Do not think HTTP Basic is a bad design choice with SSL for securing your service. Any security is brittle if you don't understand what you are upto. That said key based authentication is more apt for APIs.

People who can.
Post reply on HN