Overview of HTTP Authentication Author: David Zimmer Site: http://sandsprite.com/Sleuth ----------------------------------------------------------------------------------- The HTTP 1.x protocol has a built in mechanism for requiring a valid username/ password to gain access to web resources. This mechanism is known as HTTP Authentication and can be initiated by either a CGI script or by the web server itself. The overall purpose of this document is to provide the new user with a common sense definition and understanding of HTTP authentication at the HTTP Header Level. There are currently 2 modes of authentication built into HTTP 1.1 protocol, termed 'Basic' and 'Digest' Access Authentication. Basic Authentication transmits the username:password pair in an unencrypted form from browser to server and in such should not be used for sensitive logins unless operating over an encrypted medium such as SSL [1]. Digest Authentication sends the server a one way hash of the username:password pair calculated with a time sensitive, server supplied salt value. Here a couple definitions are in order: One way hash: a mathematical calculation of a string so that no two strings can have the same hashed value. The term one way in conjunction with this signifies that the original string cannot be recovered from the hashed value by calculation and could only be determined by brute force comparisons with the hashed values of known strings. Salt value: The salt value is an arbitrary string of data generated by the server for the client to included in the hash calculation. The use of a salt value means that every authentication attempt with the same username:password pair will result in a unique hash and is not vulnerable to replay attacks. The Digest Authentication Mechanism was developed to provide a general use, simple implementation, access control that could be used over unencrypted channels. Users should note that it is not as secure as Kerberos or client-side private-key authentication mechanisms. It is also important to note that only the username:pasword is protect by the hashing mechanism and that without the use of an encrypting medium such as SSL all retrieved documents will still be visible to all parties with access to network traffic. With the terminology and background in place we will now move on to stepping through an actual Basic Authentication exchange between Client (Web browser) and Server. 1) Client sends standard HTTP request for resource GET /download/report.doc HTTP/1.1 Accept: application/msword, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Host: 10.0.0.5:81 Connection: Keep-Alive 2) Server reads configuration files and determines that resource falls within a protected directory. Server can only allow access to known users. 3) Server Sends HTTP 401 Authorization Required Response HTTP/1.1 401 Authorization Required Date: Sat, 20 Oct 2001 19:28:06 GMT Server: Apache/1.3.19 (Unix) WWW-Authenticate: Basic realm="File Download Authorization" Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 [ html error page for browser to show if user hits cancel ] 4) Browser displays Username/ Password prompt displaying host name and authentication realm. [image auth.jpg] 5) Client Resubmits Request with Username/ Password GET /download/report.doc HTTP/1.1 Accept: application/msword, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Host: 10.0.0.5:81 Connection: Keep-Alive Authorization: Basic ZnJlZDp0aGF0cyBtZQ== 6) Server compares client information to its user/password list. a) username : password is valid: server sends requested content. b) authorization fails: server resends 401 Authorization Required header c) Client hits cancel: browser shows error message sent along with 401 message. From the above dialogue you will notice several special fields have been added to the various Http headers. In step 3 when the server sends the the 401 response it includes a special field: WWW-Authenticate: Basic realm="File Download Authorization" The value "Basic" denotes that we are requesting the browser to use Basic Authentication. The Realm information is an arbitrary string sent to be displayed to the user commonly containing a sight message, or feedback. The image in Step 4 shows Internet Explorer's HTTP Authorization Dialogue and how it displays the sight and realm data received. [2] The user fills in the form and clicks ok. The browser automatically resends the request as seen in step 5. Here you will notice a new field has been added to the standard http request: Authorization: Basic ZnJlZDp0aGF0cyBtZQ== This is where the web browser sends the actual authorization information to the server. The Authorization field shown is composed of two values. The word Basic denotes that the login is being send in accordance with the Basic Authentication method. The block of data that follows that is the actual login as supplied by the browser. Dont let the logins appearance fool you. This is not an encryption routine, but a base 64 transfer encoding. The plain-text Login can be trivially decoded to its underlying username:password format ZnJlZDp0aGF0cyBtZQ== -> base64Decode() -> "fred:thats me" The Implementation of the Digest Authentication is exactly the same as that of the Basic Authentication process outlined above, the only difference being the number of arguments supplied to the Browser and the format of the login returned. Both Basic and Digest do have respected places in the web developers toolbox, however they should not be considered high grade protection for sensitive information or access as they do not address network level attacks. Nevertheless many functions remain for which Basic and Digest authentication is both useful and appropriate. [3] Related Documents: Configuring Apache to require Authentication: http://www.apacheweek.com/features/userauth Less Technical Description of HTTP Authorization http://frontier.userland.com/stories/storyReader$2159 More Technical Description - RFC 2617 HTTP Authentication http://www.ietf.org/rfc/rfc2617.txt Implementing HTTP Authorization from PHP http://www.php.net/manual/en/features.http-auth.php [1]- Even over SSL Basic Auth may not be wise unless your script specifically determines that the request was for https and not http or else logins could easily fall victim from an uncarefully (or specifically) written links [2]- Users should be cautioned to look at the Sight: entry carefully before submitting any login data. As the Realm information is supplied arbitrarily by the remote server it could contain any information even claiming to be another sight. [3]- For in-depth coverage of limitations, security concerns, and applicable usage of HTTP Authentication refer to Section 4 of RFC 2617 ( http://www.ietf.org/rfc/rfc2617.txt )