Hacker News Reader

Comment by lucaspiller | Hacker News Reader

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 with a 401 Unauthorised status and a WWW-Authenticate header indicating what authentication to use. The client will then make another request with the given authentication.

The insecurity is caused by curl not doing this challenge response, it is just sending the credentials straight away.

View on HN

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.

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.

I agree, and the practice of sending an Authorization header without first receiving a challenge is common enough that there's a phrase for it: preemptive authentication.

See, for example, the Apache HttpClient documentation: http://hc.apache.org/httpclient-legacy/authentication.html#P...

There are two ways to look at it: cURL is the client, or the application's the client--in this case the guy writing the blog post. In either case, the client's not following the spec. So which way to look at it is correct?

My view is that cURL not a client. It's a lowish-level library and command line tool that can turn input into a format that an HTTP server can understand. Of course what puts a kink in this view is that it does things like follow redirects. A convenience for the user if anything. But in the end, you use cURL to build HTTP clients. It's not a client itself.

Regardless, you're right. It's a problem with the client not following the HTTP spec. However, I don't think many developers really follow the HTTP spec to begin with. For most, HTTP is URLS, headers, and a limited number of methods. I've certainly been guilty of viewing it as such in the past.

So in Platonic heaven, it's the client's fault and by extension the developer's fault. Does that means that API providers should let developers shoot themselves in the foot? Probably not.

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.

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.

Reply on news.ycombinator.com