Talk:Basic access authentication

From Wikipedia, the free encyclopedia

I fail to see how this isn't contradictory : Although the scheme is easily implemented, it relies on the assumption that the connection between the client and server computers is secure and can be trusted. Specifically, the credentials are passed as plain text and could be intercepted easily. The scheme also provides no protection for the information passed back from the server. To prevent the user name and password being read directly, they are encoded as a sequence of base-64 characters before transmission. Is data encrypted or not?--Chealer 09:23, 2005 Jan 22 (UTC)

I make the distinction between encoded and encrypted. Encrypted implies that the data is either a hash that cannot be reversed, or can only be decoded with some form of private key. As an example of encoded data, consider taking the letters of the password and shifting them one place in the alphabet, so Aladin becomes Bmbejo. The base-64 encoding isn't really any harder to decode, it just means – as I've said in the article – that the user name and password cannot be read directly. It provides no real security whatsoever, unlike digest access authentication.  — Lee J Haywood 09:54, 22 Jan 2005 (UTC)

Contents

[edit] caps and encryption

Two questions: First the easy one: Should this article be moved to Basic Authentication Scheme? If not, should template:lowercase be dropped into the start of it?

Now the real question: Does password authentication in HTTPS use the same protocol? If so, is it encrypted with the rest of the traffic? Is that what the editor is getting at when calls for real encryption to be used? MrZaiustalk 04:01, 19 March 2007 (UTC)

There is no compelling reason why the article title should be capitalised – see Wikipedia:Naming_conventions. There is a big difference between authentication and encryption. HTTPS itself most certainly does NOT rely on any authentication schemes, as it actually uses public-key cryptography to secure the entire request and response – including the URL. I can only assume that the same authentication schemes are supported by HTTPS as with HTTP, but they are independent of it. The comment about security is with regard to the password being passed essentially as 'plain text', such that anyone intercepting a request can read it. With digest access authentication the password is never sent in the first place, but even that scheme has its limitations. HTTPS does concern itself with 'authenticating' the site a browser connects to (via the use of certificates), but the basic authentication scheme relates to authenticating individual users (and potentially presenting different views of the web site to each person). In practice, a lot of sites just have a HTML page with a user/password box which can be even less secure than the outdated digest access authentication scheme.  — Lee J Haywood 19:55, 19 March 2007 (UTC)

[edit] Link Suggestion

This is not spam, I really like that article and recommend it to people all the time.. what do you guys think? --Produke 09:02, 31 March 2007 (UTC)

If you have a genuine link that is relevant then you should just add it yourself. The page you have suggested doesn't seem specific to the article, however – I would suggest http://www.askapache.com/docs/2.0/howto/auth.html instead. Thanks.  — Lee J Haywood 13:17, 31 March 2007 (UTC)

[edit] Base64 Encoding

Hi. I don't think base64 encoding is used in order not to be read directly by anyone. I think it's used because of the fact that passwords may contain special characters, unprintable (i.e. binary) characters, etc. that can't be transmitted as is. I would therefore suggest to change the sentence

To prevent the user name and password being read directly by a person, they are encoded as a sequence of base-64 characters before transmission.

into something like

As user name and password may contain special or even binary characters, they are encoded as a sequence of base-64 characters before transmission.

--Wurzlsepp 12:35, 16 May 2007 (UTC)

You might be right, or the article may be. Since this is an encyclopaedia, the article should be backed-up by an appropriate reference if one can be found. I suspect that the scheme pre-dates the widespread use of Unicode, but that's just an opinion. I don't see anything in the RFCs to say why base 64 was used, so more research is needed. Thanks.  — Lee J Haywood 22:10, 16 May 2007 (UTC)
I must disagree with Wurzlsepp. RFC 2617 defines the password field as type *TEXT. This is not incompatible with the HTTP field-content definition of RFC 2616, which is also *TEXT. Therefore, all valid password octets are valid header octets, and no character escaping is required. As far as "special characters"; RFC 2616 does exclude 0x00-0x08, 0x0b-0x0c, 0x0e-0x1f, and 0x7f from TEXT. I would conclude that the "special or even binary characters" of the username and password fields do not necessitate base-64 encoding for any reason. Weak obfuscation of the plain text credentials was a more likely motivation. Miqrogroove 09:38, 24 July 2007 (UTC)
Multiple specifications seem to take quite a fondness of Base64 encoded data. I would presume this to be because of the state of the internet during the time of which all of these specifications were being developed -- while as time progressed and most of the systems were being upgraded to more current hardware and software to support the 8-bit encodings, I would wager that there were still quite a few networked systems out there that could not cleanly handle 8-bit data in HTTP and such specifications.
Base64 encoding the data provided a fully backwards-compatible way of sending much more complex data while still retaining full future-compatibility. In all reality, one could still safely (albeit not effectively) use Base64 encodings, to transmit a bogus 32-bit-per-character encoding, no matter how old the systems it goes through and interacts with. If you Base64 encode such data, you would still end up with bytes that all still have the high bit nulled out, providing full backwards compatibility.
A 33% increase in size like the Base64 encoding offer was (and still is) quite a set back when the standard was created, but it was probably the most efficient method of encoding data for backwards compatibility at the time it was created.
(Wesley Spikes) 71.104.146.63 (talk) 05:15, 25 April 2008 (UTC)

[edit] Spelling

HTTP response 401: Unauthorised or Unauthorized? —The preceding unsigned comment was added by 192.54.144.229 (talk) 15:15, August 20, 2007 (UTC)

I spelt it the way it appears in my web servers. The text is not used by the computer, and is only for reading by humans so both spellings are perfectly valid. Thanks.  — Lee J Haywood 19:15, 20 August 2007 (UTC)
The spelling difference is due to international localization of language. I believe, and correct me if I'm wrong, that "Unauthorised" is the UK English spelling of it, while "Unauthorized" is the US English spelling. 71.104.146.63 (talk) 05:19, 25 April 2008 (UTC)

[edit] Support by Web Browsers

The line "One advantage of the basic access authentication is that it is supported by almost all popular web browsers." is questionable, but I'll submit it to talk. I believe Basic Auth is supported by ALL popular web browsers. I've never heard of one that doesn't support it and if there is one, I would wager it's certainly not popular. Anyone have any examples of a popular web browser that doesn't support basic auth? JordanHenderson (talk) 23:08, 1 January 2008 (UTC)

Assuming that "popular" is greater than .2% of the market share usage, than according to Comparison of Web Browsers, as retrieved just now, all "popular" web browsers support HTTP/1.1's basic authentication methods. The only one on the comparison list that does not is Mosaic, which only got to HTTP/0.9 support. As such, I will commit a change on the main page, as I believe that no one will ever find any such browser. (Wesley Spikes) 71.104.146.63 (talk) 05:26, 25 April 2008 (UTC)