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

61–70 of 136 posts

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

#61

Post by noselasd »

acqq wrote: post #56

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:…

It's pretty much like forms based auth which is used by virtually every user facing web site with a login, wherein the data you send over is plaintext.

And as we know, that needs to be done over TLS.

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

#62

Post by kbutler »

psionski wrote: post #45
sjtgraham wrote: post #16

Earlier quoted context omitted.

Great TL;DR. Is that algorithmically generated or by a human?

So you don't mind people butchering your words? I'd be offended if someone created a TL;DR of one of my posts...

tl;dr: Summarizing offends me

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

#63

Post by psionski »

kbutler wrote: post #62
psionski wrote: post #45

Earlier quoted context omitted.

So you don't mind people butchering your words? I'd be offended if someone created a TL;DR of one of my posts...

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

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

#64

Post by mechanical_fish »

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

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 across a bunch of different systems no matter how frantically we wave our hands, and (most important of all) have "user" semantics and scope: a password lets a user log in and do logged-in-user stuff.

Whereas an API key can be issued by the system, and is thereby guaranteed (assuming a clueful programmer) to be long and random and unique and not shared with the customer's Gmail account and bank account. You can expire it often. You can issue more than one per customer. (With passwords, this is theoretically possible but practically impossible; customers barely understand how to handle one password.) You can issue it to entities that aren't themselves customers, and that don't have "user" semantics. You can scope it to particular uses, issuing a key that is only good for checking balances but not for initiating transactions, for example.

---

[1] The other being cache coherency. And avoiding off-by-one errors when enumerating lists.

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

#65

Post by crazydoggers »

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.

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

#66

Post by [deleted] »

lucaspiller wrote: post #9

Isn't this is a problem with the client, curl in this case? According to the spec: > HTTP provides a simple challenge-response authentication mechanism which may be used by a server to challenge a client request and by a client to provide authentication information. The client should make two requests. The first with no credentials to see if the resource is protected (the challenge part). The server will then respond…

[deleted]

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

#67

Post by pifflesnort »

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.

I've implemented OAuth client-side a few times in a few languages. The signing process itself may not be that difficult to understand, but there are a lot of fiddly moving pieces, the specs are painful to read, and everyone has their own unique take on the spec.

I wouldn't call it simple. It's complex to get right, and outright damaging to non-web clients except in the case where xAuth or similar is available.

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

#68

Post by noselasd »

lucaspiller wrote: post #9

Isn't this is a problem with the client, curl in this case? According to the spec: > HTTP provides a simple challenge-response authentication mechanism which may be used by a server to challenge a client request and by a client to provide authentication information. The client should make two requests. The first with no credentials to see if the resource is protected (the challenge part). The server will then respond…

Yes, Basic auth is the default in curl, if you provide credentials off the bat. Use --digest to default to digest auth.

If you don't provide credentials, curl will prompt you and do the authentication the server requests (if any). Using --anyauth will also let the server decide.

They're probably not going to change that default and break millions of scripts on the next apt-get upgrade.

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

#69

Post by barredo »

smtddr wrote: post #40
barredo wrote: post #33

Earlier quoted context omitted.

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 l…

Makes total sense. Thanks

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

#70

Post by Adirael »

miorel wrote: post #8
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 proper response should be to expire the insecurely-sent passwords.

Clever. I like this much more than just closing the port 80.
Post reply on HN