[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RE: Encoding charset of HTTP Basic Authentication
> 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|