Talk:Basic access authentication

encoded and encrypted

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 reset

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? MrZaius^talk 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]

هلا اهلين Moom 2 (talk) 03:37, 11 June 2017 (UTC)[reply]

Link Suggestion

Troubleshooting Basic Authentication on the Apache Web Server

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]

@Miqrogroove: in its definition of TEXT, RFC2616 says that *TEXT may contain 8-bit characters but if they are not from ISO-8859-1 charset (that is, Latin-1 or so-called "Extended ASCII"), then they must be MIME encoded. In this case, I would say it's better to always encode this field since virtually any charset can be used on client side. Trying to hide a password using MIME encoding is ridiculous! Anybody able to read a HTTP header is capable of using a MIME decoding tool too (or writing two lines of code). IETF guys are not that silly: obfuscation is absolutely useless if we talk security, so it can't be the reason. The only reason which is expressed in RFC2616 is the encoding of special characters and it makes sense, so I think it's better not to speculate. Evoisard (talk) 10:32, 13 October 2011 (UTC)[reply]

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

The extended discussion, including small examples to decode, of Base64 seems inappropriate to this article. There's a separate article on Base64 enoding (that needs citations and references, btw) that could be referenced here. I'm not bold enough, or maybe I'm just too lazy to make this edit. I agree with Lee J Haywood above that the suppositions about the motivations for Base64 encoding in this article is just speculation or original research without reference to original sources. JordanHenderson (talk) 16:19, 20 September 2009 (UTC)[reply]

I agree that this list of examples in almost any programming language is absolutely ridiculous. This is not a contest on best looking languages, nor an article about MIME decoding. I would remove this entire section which is out of topic! Evoisard (talk) 10:32, 13 October 2011 (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]

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

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

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

Disadvantages

There is a way to implement logout: The server has to send 401 for the realm ignoring the credentials. This will popup the login dialog in the browser again.

The implementation in JSP looks like this logout.jsp

<%
  if (null == session.getAttribute("__logout__seen")) {
    // if this page is invoked first, we send a login failure
    // so the browser prompts for user/password again
    response.addHeader("WWW-Authenticate", "Basic realm=\"your realm\"");
    response.sendError(401);
    // and we mark that we sent the 401
    session.setAttribute("__logout__seen", "yup");
  } else {
    // then we invalidate the session and redirect to the application
    session.invalidate();
    response.sendRedirect("index.html");
  }
%>

User:StefanFranke —Preceding undated comment added 09:22, 15 March 2009 (UTC).[reply]

Another way to "log out" is to track the user's realm, and change to log them out. — Preceding unsigned comment added by 67.128.187.35 (talk) 17:28, 20 March 2012 (UTC)[reply]

ANSI C code sample

The code sample supplied is not valid ANSI C, the encode_base64() and decode_base64() do not exist either in any C-related standard, nor does the syntax used look like the functions exist anywhere in this form at all. In any reasonable implementation, you would have to supply the output buffer as an argument to that function and normally also the length (for binary data).

212.66.157.114 (talk) 10:28, 3 September 2010 (UTC)[reply]

Agreed. Removed. --ChrisRuvolo (t) 21:30, 8 April 2011 (UTC)[reply]

user@password URLs

Mention that one can use http://USER:PASSWORD@example.com/ URLs too, in many browsers, but not IE. Jidanni (talk) 02:28, 5 September 2010 (UTC)[reply]

There are many other methods of authentication in HTTP. ?

I don't want to start an edit war, but this is inaccurate. HTTP supports exactly one other methods of authentication, Digest access authentication. There are numerous other authentication methods used over HTTP links, but Basic access authentication and Digest access authentication are the only two referenced in the HTTP Protocol documents, specifically in RFC2617

Other authentication schemes have been used involving interaction with a HTTP client and programs on an HTTP Server (sometimes involving Web Browser client side programming), but these aren't part of the HTTP protocol. HTTPS supports authentication via X.509 Certificates, but HTTPS is a layer on top of HTTP.

I'm replacing this edit with another edit that highlights the two supported authentication methods in HTTP.JordanHenderson (talk) 03:11, 3 March 2011 (UTC)[reply]

Done. Even if there were many other methods of authentication in HTTP, this observation doesn't belong at the start of the Advantages section. JordanHenderson (talk) 03:16, 3 March 2011 (UTC)[reply]

Role based access

Basic access authentication, in combination with SSL authentication, is a good way to provide a role based access to a resource. The username can be used to establish the users role, while SSL certificates provide the authentication of the user. Is this observation appropriate for this article? Or is this more of a discussion topic for a forum somewhere? JordanHenderson (talk) 01:48, 20 August 2011 (UTC)[reply]

Unnecessary collection of trivial code examples.

From the article. This collection is not encyclopedic and the different examples are almost all trivial and similar. I selected the PHP example to stay in the article (I don't use it myself so it's not such a bias, PHP selected for relative fame and use in relation to the web.) See [[1]] -- Sverdrup (talk) 17:17, 14 October 2011 (UTC)[reply]

in Groovy:

println "Aladdin:open sesame".bytes.encodeBase64().toString()
println new String("QWxhZGRpbjpvcGVuIHNlc2FtZQ==".decodeBase64())

in TCL:

puts stdout [::base64::encode {Aladdin:open sesame}]
puts stdout [base64::decode {QWxhZGRpbjpvcGVuIHNlc2FtZQ==}]

or

set userName Aladdin
set password "open sesame"
puts stdout [::base64::encode $userName:$password]
set token  {QWxhZGRpbjpvcGVuIHNlc2FtZQ==}
puts stdout [base64::decode $token]

in PHP:

echo base64_encode("Aladdin:open sesame"), PHP_EOL;
echo base64_decode("QWxhZGRpbjpvcGVuIHNlc2FtZQ=="), PHP_EOL;

in Python:

import base64
print base64.b64encode("Aladdin:open sesame")
print base64.b64decode("QWxhZGRpbjpvcGVuIHNlc2FtZQ==")

in C#:

using System;
using System.Text;
Console.WriteLine(Convert.ToBase64String(Encoding.UTF8.GetBytes("Aladdin:open sesame")));
Console.WriteLine(Encoding.UTF8.GetString(Convert.FromBase64String("QWxhZGRpbjpvcGVuIHNlc2FtZQ==")));

or

using System;
using System.Text;
Console.WriteLine(Convert.ToBase64String(ASCIIEncoding.ASCII.GetBytes("Aladdin:open sesame")));
Console.WriteLine(ASCIIEncoding.ASCII.GetString(Convert.FromBase64String("QWxhZGRpbjpvcGVuIHNlc2FtZQ==")));

in Perl:

use MIME::Base64;
print encode_base64('Aladdin:open sesame');
print decode_base64('QWxhZGRpbjpvcGVuIHNlc2FtZQ==');

in Erlang:

1> base64:encode(<<"Aladdin:open sesame">>).
<<"QWxhZGRpbjpvcGVuIHNlc2FtZQ==">>
2> base64:decode(<<"QWxhZGRpbjpvcGVuIHNlc2FtZQ==">>).
<<"Aladdin:open sesame">>

in Ruby:

require 'base64'
puts Base64.encode64('Aladdin:open sesame')
puts Base64.decode64('QWxhZGRpbjpvcGVuIHNlc2FtZQ==')

in JavaScript (Firefox, Chrome, Safari browsers):

console.log(btoa("Aladdin:open sesame"));
console.log(atob("QWxhZGRpbjpvcGVuIHNlc2FtZQ=="));

or (NodeJS)

console.log(new Buffer('Aladdin:open sesame', 'utf8').toString('base64'));
console.log(new Buffer('QWxhZGRpbjpvcGVuIHNlc2FtZQ==', 'base64').toString('utf8'));

in Pike:

write(MIME.encode_base64("Aladdin:open sesame"));
write(MIME.decode_base64("QWxhZGRpbjpvcGVuIHNlc2FtZQ=="));

String literal?

The resulting encoded string is not a string literal. A string literal is something typed directly into the source code, but the encoded string is computed (concatenate username, colon, password). Computed strings aren't literals. — Preceding unsigned comment added by 24.234.119.49 (talk) 02:00, 26 September 2012 (UTC)[reply]

Vague

It is essential to give an example of a soap messaging containing basic authentication. How basic authentication manifest itself into static soap headers is not obvious; yet that is the subject and point of the article. In particular, are there predefined headers and/or value constraints. After some consideration, it seems the authentication headers must be included in every request and that this requirements distinguishes if from that which uses session cookies, following the initial handshake. — Preceding unsigned comment added by 99.245.3.15 (talk) 03:40, 13 March 2013 (UTC)[reply]

Looked biased towards IE

Looked biased towards IE — Preceding unsigned comment added by 192.193.216.148 (talk) 04:08, 29 April 2015 (UTC)[reply]

😂 Moom 2 (talk) 03:56, 11 June 2017 (UTC)[reply]

Add link for this article to Template:HTTP?

This article uses Template:HTTP. However, the links from that template do not include a link to this article. Shouldn't a link to it be included in the template? --Lance E Sloan (talk) 14:40, 12 May 2016 (UTC)[reply]

Title (adding HTTP adjective to be more descriptive)

I would suggest new title HTTP Basic access authentication in stead of Basic access authentication — Preceding unsigned comment added by Tech201805 (talk • contribs) 09:58, 24 May 2018 (UTC)[reply]

gXvoqaFzd1jYQ9f13sPO06 103.23.36.49 (talk) 17:45, 17 September 2024 (UTC)[reply]