Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

RFC 2617 requires that in HTTP Basic authentication, the username and password must be encoded with base64.

To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a base64 encoded string in the credentials.

  basic-credentials = base64-user-pass
  base64-user-pass  = <base64 encoding of user-pass,
                   except not limited to 76 char/line>
  user-pass   = userid ":" password
  userid      = *<TEXT excluding ":">
  password    = *TEXT

Userids might be case sensitive.

If the user agent wishes to send the userid "Aladdin" and password "open sesame", it would use the following header field:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Since base64 encoding offers zero security of the credentials, why is this done?

share|improve this question
up vote 38 down vote accepted

It is not done for security reasons at all, and more as a means of escaping special characters

TLS would be employed for security.

share|improve this answer
This makes sense, it would be a shame if a user would have two new lines in his password. – droope Jan 30 '13 at 5:21
In search of maximum entropy, my password includes three new lines – BrianAdkins Jan 30 '13 at 5:24
Of course as a means of including tricky characters it's still pretty much a failure - you still can't get a colon into the username, or any non-ASCII Unicode characters into username or password, because there isn't a standard byte encoding to apply before base64, and browsers all choose different encodings. The Basic Auth protocol is just poorly designed in general. – bobince Jan 30 '13 at 11:45
@bobince, regarding encoding, the MIME RFC clearly defines the meaning of TEXT in userid and password fields. The fact that most browsers are non-compliant is another matter entirely. – avakar Jan 30 '13 at 12:09
@BrianAdkins so this is naive? – Metalcoder Oct 24 '13 at 13:16

Its fairly simple really. Its just (like all poor security) a trade off between the time/effort required to implement it and the security of the product. In this case, its simple to implement but very insecure as you've demonstrated.

To quote wikipedia

HTTP Basic authentication implementation is one of the easiest ways to secure web pages because it doesn't require cookies, session handling, or the development of login pages. Rather, HTTP Basic authentication uses static headers which means that no handshakes have to be done in anticipation. Programmers and system administrators sometimes use basic access authentication—in a trusted network environment—to manually test web servers using Telnet or other plain-text network tools. This is a cumbersome process, but the network traffic is human-readable for diagnostic purposes. One other advantage of basic authentication is that it avoids the double hop authentication problem that can cause problems for protocols such as NTLM.

To assist in securing the login, using TLS/SSL would be reccomended as well.

Hope that helps!

share|improve this answer
No it's not done for security, just because the field is in an HTTP header and odd characters could make the entire HTTP request invalid. – LtWorf Feb 9 '13 at 22:46

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.