cURL / Mailing Lists / curl-library / Single Mail


RE: Order of HTTP auth schemes

From: Joe Mason <>
Date: Wed, 27 Mar 2013 22:39:16 +0000

> From: curl-library [] on behalf of Daniel
> Stenberg []
> Sent: Wednesday, March 27, 2013 6:09 PM
> To: libcurl development
> Subject: RE: Order of HTTP auth schemes
> I've read most of the available HTTP auth specs at least twice. I'm quite sure
> that there's no such thing as a prio list anywhere in any HTTP (auth) spec.

Right, that's why I said "standard practice". :-)
> But sure, Chromium clearly uses that order and since the brower teams tend to
> copy each other very closesly I can quickly guess that all the other big
> browsers do it in the same way.

Except, apparently, IE, which uses the first one encountered unless it's Basic. (According to that doc.)

> > curl prioritizes "Digest" ahead of "NTLM":
> > What's the reason for this, and would you be open to swapping it?
> I came up with our existing order and as I'm not convinced that NTLM is
> automatically a better auth than Digest, I made Digest preferred since it A)
> is a real documented standard and B) follows HTTP paradigms that NTLM doesn't.

Yeah, I despise NTLM, but unfortunately lots of servers want to use it...

I think the reason NTLM is preferred by many server admins is that it hooks into Windows authentication mechanisms by default so it's easy to set up NTLM auth to allow any domain user to connect, with whatever complicated processing is done by the domain controllers. It's perceived as a more "enterprise" auth solution than Digest.

It also has some extra auditing extensions that can lead to better overall security, even if the basic mechanism of transferring credentials isn't any more secure than Digest. (Although I'm not sure if curl supports them.)

> > I wonder if there should be an option to set the priorities for each -
> > although I recommend hardcoding BASIC to be the lowest priority.
> I've considered but I've never figured out a proper use case for when someone
> would actually want a different order. The point of the order is to select one
> out of N working ones. It shouldn't be possible to select the wrong one from a
> functional stand-point, so the list should really be in a rough "most secure"
> order and I can't think of good reasons why the secure order would change. Can
> you?

I don't think any one app would vary the order, it's more a matter of giving control to the app author - if they disagree with curl's default choice of ordering they could override it.

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

List admin:
Received on 2013-03-27