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

71–80 of 136 posts

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

#71

Post by mnarayan01 »

rapala wrote: post #28
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…

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.

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

#72

Post by mnarayan01 »

noselasd wrote: post #68
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.

Additionally, if you want a more high level interface which makes multiple requests per command, wget is a good option.

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

#73

Post by rst »

martin-adams wrote: post #55

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…

I think the idea is that if the real port 80 never answers, real customers are highly unlikely to set up their apps in the vulnerable state in the first place. That said, having port 80 open, but returning an appropriate error code to all attempts to use the API, would probably have the same effect (while still answering on port 80, for anyone who just wants to ping it to see "are they up" --- one of the excuses the OP has heard for leaving port 80 open).

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

#74

Post by rb2k_ »

quesera wrote: post #38
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.

I was talking about Message Authentication Codes rather than the Macintosh line of computers :)

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

#75

Post by chmullig »

rst wrote: post #73
martin-adams wrote: post #55

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…

I think the idea is that if the real port 80 never answers, real customers are highly unlikely to set up their apps in the vulnerable state in the first place. That said, having port 80 open, but returning an appropriate error code to all attempts to use the API, would probably have the same effect (while still answering on port 80, for anyone who just wants to ping it to see "are they up" --- one of the excuses the…

No, that's exactly the problem the post is complaining about. It still results in credentials being sent in plaintext in the original request.

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

#76

Post by poutine »

mechanical_fish wrote: post #64
corresation wrote: post #51

Earlier quoted context omitted.

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

You also hash the two differently in your database. With passwords you want to bcrypt (or similar) them to protect against exposure of the DB and an attacker brute forcing the hashes. Since this is virtually impossible for long random strings you're able to just SHA2-256 the keys for DB storage. This becomes important because you're likely checking the key every API request and bcrypt would be a significant API rate limiter.

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

#77

Post by Joeri »

mechanical_fish wrote: post #64
corresation wrote: post #51

Earlier quoted context omitted.

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

Arbitrary distinction. A password can be expired and forced to comply with complexity rules. A key is a server-side generated password, and therefore offers less ability for users to implement their own password policies. Good for users that don't care, bad for users that do care.

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

#78

Post by wickedshimmy »

crazydoggers wrote: post #65

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

This is a very good point, and is the sort of situation where API tokens can come into play and be useful. A client can make a single request to "open a session" and receive a short-lived key that is used as the password credentials for subsequent requests. Store active keys - since they are short-lived, offline attacks are less of a concern and you can probably choose to not slow-hash them. When the token expires and a request fails authentication, the client simply requests a new one and retries. The token lifetime is a much easier adjustment for which to weigh security versus performance/load considerations, compared to against broader password storage security.

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

#79

Post by poutine »

crazydoggers wrote: post #65

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

This isn't a problem specifically with HTTP basic which at the end of the day is just a HTTP request header with an encoded string.

If you're using basic auth and a long random server generated key as Stripe does instead of a user supplied pasword performance is a non issue as you'd SHA2 it in your DB not bcrypt.

Post reply on HN