Jump to content

Talk:Basic access authentication

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Apacheguru (talk | contribs) at 01:53, 26 November 2007 (Undid revision 170981172 by S600 (talk)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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)

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Basic_access_authentication&oldid=173799929"