Re: [xml-dev] RE: Encoding charset of HTTP Basic Authentication

[Richard Salz <rsalz@us.ibm.com>]

> My understanding is that Basic is essentially considered insecure.

Well, sending name/password over the Internet in the clear is bad. :) 
Basic-auth is just name/password encoded in base64.  It's not encrypted, 
nobody treats base64 as encryption. But back when basic-auth was created 
(like pre-apache golden oldie days), everyone on the internet was Gentle 
and Kind and followed Stimson's rule of "gentlemen don't read each other's 
mail."

One could say that base64 was chosen to future-proof and allow for 
multi-charset data, but I think that's kinda revisionist.  At the time of 
its definition, multiple charsets were not defined or in use in IETF 
protocol headers.

>  I'd be 
> surprised if modern browsers support it because it opens the way to a 
> man-in-the-middle downgrade attack.

I think you're confused.  Every single browser understands and supports 
basic-auth, and the HTTP status code for auth-required (401).  An MITM 
downgrade is when the adversary manages to trick both sides into using 
weaker security mechanisms, such as using DES insead of AES-256.  Digest 
is susceptible to MITM -- is that what you meant?

The problem with basic-auth is that it requires the name/password to be 
sent on every single request. The more a password is used, the more it as 
at-risk. Even over SSL/TLS.  Digest is better because it never sends the 
password over the wire. It's worse because 

Hope this helps.

        /r$

--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/