[pyre]

Maybe I'm missing something, but is the general consensus on HTTP Auth that it's poor security? I've seen is suggested a lot of (e.g.) authentication in webapp <=> api scenarios. Specifically to use it to pass the initial username/password, and then stuff an session token into it (after login). What are the added security risks of this (so long as it's done over HTTPS)?

[mmalone]

For webapp <=> API it's pretty much the same as any other header, but with a subtle semantic indication that the value associated with the header is being used for authentication. Generally the value is a password or a bearer token. The problem is that this token is usually not channel bound (can be stripped and used elsewhere) and often has broad authorization associated with it. The security characteristics depend on lots of details. Usually when people say not to use HTTP Auth they mean don't send the username / password in base64 encoded cleartext over the open internet, as suggested by early HTTP RFCs.

[aeronautic]

Do you mean basic & digest http auth built into the browsers? If so, yes, they are bad. The issue is you cannot reliably implement log off on all browsers.

[jessaustin]

Is this still true, for any browser that is still used? It seems a couple of decades would be long enough to get this right...

[aeronautic]

Still true when I tested last year. The core protocol does not have a defined way to get the browser to forget the login.

You have to resort to different fudges on different browser.

Net/Net: the http auth ui sucks, has bad usability, weak crypto, and is not robust with logout.

HTML/form based auth can be made robust and is a preferable alternative in every case.

[pyre]

I'm taking about using the 'Authentication: ' headers, not relying on the browser's handling of auth (other than making the requests).