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

21–30 of 136 posts

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

#21

Post by hrrsn »

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, implementing a library, etc.

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

#22

Post by eigenvector »

sjtgraham wrote: post #16
louischatriot wrote: post #12

This is an important issue, but as the article says, Auth Basic over SSL is perfectly secure (if you don't redirect 80 to 443 of course). And since it is so simple to set up and use, I can see why some providers would use it (I do for example). Summary of the article: http://tldr.io/tldrs/516fc7e340d4a84c4100020e/why-the-hell-d...

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

It's crowd-sourced from actual people using a browser extension.

http://tldr.io/what-is-tldr

(see how I gave you a tl;dr of the link explaining how the tl;dr is generated?)

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

#23

Post by masklinn »

FooBarWidget wrote: post #13
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…

Some web apps don't return 401 Unauthorized. They simply display different content when there's no authentication information.

This is an API endpoint, not a web application.

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

#24

Post by emtunc »

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 the user a choice?). You would be surprised to see how many apps ignore SSL errors and allow you to use any old self signed cert.

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

#25

Post by jamescun »

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…

While if you are just implementing Key/Token auth for an API, Digest might be `good enough` but does not escape the problems associated with Digest, such as its reliance on MD5 (broken, if your token is complex and longer than 32 chars it renders it less secure) and the requirement to store tokens in plain-text[1].

If you are implementing username/password, then Digest removes the ability to use a secure password system like Bcrypt or PBKDF2, which is a killer.

[1] You are able to store the digested tokens/passwords rather than plain-text, but if you need to protect the token/password in any way, the digest is an insecure way to do so.

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

#26

Post by drivebyacct2 »

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.

Isn't this sort of issue basically only going to happen during development or such?

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

#27

Post by fiorix »

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.

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

#28

Post by rapala »

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…

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 Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server.

which would imply that at least one 401 response should be received before sending credentials.

Of course the most important part of the spec is this:

The Basic authentication scheme is not a secure method of user authentication, nor does it in any way protect the entity, which is transmitted in cleartext across the physical network used as the carrier.

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

#30

Post by geon »

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.

Sending the password more or less in plain text is defined by the http standard. It's not a bug per see...

And I doubt you can convince any browser maker to drop basic auth support.

Post reply on HN