Abstract

For any task involving personalization and/or trust, it is not only necessary to have a concept for providing privacy, but also to have concepts for identity and how to prove identity, which needs authentication. HTTP has built-in mechanisms for authentication, and the standard HTTP Authentication mechanisms are Basic Authentication and Digest Access Authentication. Instead of these mechanisms, many applications implement their own ways of authentication, which often are based around authentication using HTML Forms.

Certificates and Identity

• What can you be certain of when using HTTPS?
  • in most cases there only is a server side Certificate
  • if attackers can manipulate your DNS they can attack HTTPS
• Many scenarios require reliable identification of the client
  • HTTPS supports client side certificates for identifying clients
  • rarely used outside of closed user groups
• Traditional user identification against a trusted server
  • trusted servers can be used for securely transmitting authentication credentials
  • identity and authentication methods are handled on a per-server basis
  • when using many services, users end up with many identities

Usernames and Password

• Usernames represent identities
  • whoever uses the name is identical with the user
  • giving away the username means giving away the identity
• Passwords are used to authenticate a user
  • identities are secured and checked by using password
  • giving away the password means giving away the authenticity
• Usernames and passwords must be handled securely
  • transmitting them in clear text (such as HTTP) is a very bad idea
  • reusing username/password pairs is a risky practice

HTTP Access Control

• HTTP servers can deny access because of access control
  • 401 Unauthorized means the resource is access controlled
  • 403 Forbidden means the resource is inaccessible
  • 405 Method Not Allowed signals a request using the wrong request method
• Two different approaches to unauthorized access are possible
  • repeat the HTTP request with the proper authentication credentials
  • redirect to a Login Page and establish an authenticated Session

HTTP Authentication

Authentication Information

• Authentication is based on authentication realms
  • a set of resources for which the authentication is required
  • an opaque name which is used to signal which login is required
  • username/password probably is specific for a given realm
• Users supply username and password through the client
  • sent as Base64 encoded username:password string
  • username and password are not transmitted securely
  • basic authentication should always use HTTPS
• Authorization is handled on the server side

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm="SokEvo"

GET /private/index.html HTTP/1.0
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Repeated Access

• Clients typically access more than one protected resource
  • a perfectly stateless client would always request authentication from the user
  • using the Authentication Information clients can identify repeated accesses
• Clients remember the authentication and replay it automatically
  • browsers provide little control over this feature
  • logging out of HTTP authenticated sessions is hard

Better HTTP Authentication

• Basic Authentication is a serious security problem
  • username and password are transmitted unencrypted
• Digest Access Authentication does not require transmission of the password
  • only information computed using a One-Way Function is transmitted via HTTP
  • server-side needs clear-text password to compute HTTP header values
• Three-step one-way function calculation of response value
  1. HA1 = MD5(username, realm, password)
  2. HA2 = MD5(HTTP method, request URI)
  3. Response = MD5(HA1, nonce, nc, cnonce, qop, HA2)
• Server responses may include AuthenticationInfo
  • information for the next authenticated request

Example Headers

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="testrealm@host.com",
	qop="auth,auth-int",
	nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
	opaque="5ccc069c403ebaf9f0171e9517f40e41"

GET /dir/index.html HTTP/1.0
Authorization: Digest username="Mufasa",
	realm="testrealm@host.com",
	nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
	uri="/dir/index.html",
	qop=auth,
	nc=00000001,
	cnonce="0a4f113b",
	response="6629fae49393a05397450978507c4ef1",
	opaque="5ccc069c403ebaf9f0171e9517f40e41"

Login Page

• HTTP Authentication works with browser controls (including window)
  • no possibility to log out without using browser-specific controls
  • client side security depends on browser security measures
• Using HTML Forms gives more freedom in session management
  • authentication and authorization are completely application-based
  • if there were secure personal browsers this would not work very well

HTTP and Form-Based Login

• HTTP is used inconsistently with form-based login
  • some frameworks use redirections to login pages and then to resources
  • some frameworks use login pages as front ends to protected resources
• HTTP messages never indicate any kind of authentication problem
  • 302 Found is being sent for unauthenticated access (Location login page)
  • successful login redirects to the original resource
  • 401 Unauthorized signals missing authorization (no WWW-Authenticate)
• Use HTTP to display login pages
  • 403 Forbidden when requesting a protected page without credentials
  • send the login page as the HTML in the response
  • after authentication and authorization serve the same page as 200 OK
• The login representation is the preferred method

Form-Based Authentication

HTML Session Management

<form action=".../generateReport.cfx" method="post">
 <input name="vin" type="hidden" class="inputVINfield" value="{vin}"/>
 <input type="hidden" name="user" value="...@DRET.NET"/>
 <input type="hidden" name="email" value="...@DRET.NET"/>
 <input type="hidden" name="zip" value="94709"/>
 <input type="hidden" name="sessionSequence" value="070916220678735"/>
 <input type="hidden" name="encryptedSid" value="yVXQOIQV01yWJBf8EtB7hA%3D%3D"/>
 <input type="hidden" name="cardHolderName" value="Erik Wilde"/>
 <input type="hidden" name="chargeAmount" value="29.99"/>
 <input type="hidden" name="sendMeEmail" value="N"/>
 <input type="hidden" name="addressOne" value="1771 ... Street"/>
 <input type="hidden" name="addressTwo" value=""/>
 <input type="hidden" name="cfxId" value="CFX000017762596"/>
 <input type="hidden" name="city" value="Berkeley"/>
 <input type="hidden" name="state" value="CA"/>
 <input type="hidden" name="consumerId" value="10100990"/>
 <input type="hidden" name="sid" value="yVXQOIQV01yWJBf8EtB7hA%3D%3D"/>
 <input type="hidden" name="expireDate" value="20071016220836"/>
 <input type="hidden" name="reportsAvailable" value="199"/>
 <input type="hidden" name="product" value="UCP"/>
 <input id="reportButton" name="reportButton" type="submit"/>
</form>

Web or Application Architecture

• HTTP Authentication uses standards and standard mechanisms
  • Basic Authentication should always use HTTPS
  • Digest Access Authentication can be safely used over unencrypted connections
• Application Authentication uses fewer Web methods
  • some frameworks use login representations for protected resources
  • some frameworks use redirects to channel requests through a login page