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

31–40 of 136 posts

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

#31

Post by sgt »

hrrsn wrote: post #21
rb2k_ wrote: post #10

I like HTTP APIs that use basic auth over SSL. Why? Because as the blogpost demonstrates nicely, curl is a wonderful tool to test, demo and debug things. As soon as you introduce e.g. MACs to the mix, you can forget about most unix-y commandline tools. I think we can all agree that there are better options when it comes to authentication, but I'd rather have something I can work with easily than worry about that tiny…

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.

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

#33

Post by barredo »

rb2k_ wrote: post #4
barredo wrote: post #3

So if you offer a https only API and anyone makes the mistake of using http instead, what should be the response of your system? A simple error message with 404 code and without special/identifying headers?

The main problem isn't the response, the problem is that on the initial request, the insecure password will be sent in plaintext.

But that's not the problem of the API provider. If you explain that you only allow HTTPS and someone makes an HTTP on an unsecured connection, well...

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

#35

Post by kalleboo »

emtunc wrote: post #24

I was playing about with Fiddler with some mobile apps on my iPhone a while ago and noticed one app was using HTTP basic auth with HTTPS but the application was ignoring SSL errors (I was using a self signed cert on my PC to perform MITM and decrypt HTTPS traffic). This is almost as bad as using HTTP and basic auth because you're basically ignoring the fact that the certificate should not be trusted (at least give th…

We had to (begrudgingly) disable cert validation when we still supported older iOS versions, as it was impossible to find an affordingly-priced CA that issued compatible certificates.

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

#36

Post by laumars »

fiorix wrote: post #27

Why the hell would you over complicate your API with things like s3 auth or other bs like oauth? HTTP Basic Auth works pretty well with SSL and should be enough for most cases. Also, it's dead simple for the API to return a token that can be used after authentication in non-SSL endpoints of the API.

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 you really shouldn't be allowed near any sub-systems which require authentication.

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

#37

Post by kalleboo »

sergeykish wrote: post #7

Obviously it is user agent failure. Why would you want transmit private information clear text? Edit: File bug to browser makers. Personally use http proxy to remove auth and cookies from insecure traffic.

Except this in the context of APIs, you're talking about removing basic auth from the libraries that have had it for ages.

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

#38

Post by quesera »

rb2k_ wrote: post #10

I like HTTP APIs that use basic auth over SSL. Why? Because as the blogpost demonstrates nicely, curl is a wonderful tool to test, demo and debug things. As soon as you introduce e.g. MACs to the mix, you can forget about most unix-y commandline tools. I think we can all agree that there are better options when it comes to authentication, but I'd rather have something I can work with easily than worry about that tiny…

> As soon as you introduce e.g. MACs to the mix, you can forget about most unix-y commandline tools.

I'm tempted to ask which command line tools you are missing in OSX, but I'm wondering if your capitalization was intentional and correct. :)

If the latter, I've found that 10-line ruby "clients" can go a long way toward simplifying API testing.

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

#39

Post by zikzikzik »

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 rejecting connections on port 80. (Dropping packets looks even more like service outage, which was mentioned.)

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

#40

Post by smtddr »

barredo wrote: post #33
rb2k_ wrote: post #4

Earlier quoted context omitted.

The main problem isn't the response, the problem is that on the initial request, the insecure password will be sent in plaintext.

But that's not the problem of the API provider. If you explain that you only allow HTTPS and someone makes an HTTP on an unsecured connection, well...

Oh but it IS the problem with the provider. Or rather, it will be when some crazy PR storm hits the interwebz with "$YOURCOMPANYNAME leaked passwords!" when someone comes up with some clever way to hack/manipulate traffic with XSS or something. I was able to fetch private authtokens of a Wii game because port 80 was open on one of nintendo's servers(I assume it's there to test in plain text and just didn't close it later) and I was able to fool the software into using port 80 instead of port 443. That wouldn't have worked if port 80 was closed.
Post reply on HN