Basic Authentication Security

In deploying web applications, you have a couple options for authenticating your users as seen here in IIS:

Basic authentication works in the following steps:

1. An un-authenticated user requests resources

2. Server requires authentication to view resources so returns a "401 Challenge" to the browser. The HTTP Response header will contain something like this:

   
                       Copy
                       
                    
   WWW-Authenticate: Basic realm="Protected"
   

3. The browser prompts the user for their username and password and stores them internally.

4. The browser reissues the original request along with the stored credentials (encoded in base64)

   
                       Copy
                       
                    
   Authorization: Basic dG9tY2F0OnMzY3JIdA==
   

5. The server authenticates the passed in credentials against the local computer / network. Once authenticated, the browser returns the requested resource.This approach requires that the end user have an account within the server's user accounts or network.

6. On subsequent requests the browser continues to pass the saved user credentials until the browser is closed and discards the login info.

Once authenticated, the web application may also initialize some session state for the user in order to cache or persist high level information.

When it comes to timing out a user, it's important to note which elements we can control from the server and those we cannot:

Client - controls credentials
Server - controls session

On the server side you can set the session timeout,

                    Copy
                    
                 
<system.web>
   <sessionState mode="InProc" cookieless="false" timeout="25" />

The architectural design for most web applications is state

It's nice having the client and server both have their own responsibilities, but it leads to some wonky results. By default, if the session times out on the server, the client is none the wiser. Unless you have a

RFC7235 - 6.2 Authentication Credentials and Idle Clients (previously RFC2616) #

Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP does not provide a mechanism for the origin server to direct clients to discard these cached credentials, since the protocol has no awareness of how credentials are obtained or managed by the user agent. The mechanisms for expiring or revoking credentials can be specified as part of an authentication scheme definition.

Circumstances under which credential caching can interfere with the application's security model include but are not limited to:

• Clients that have been idle for an extended period, following which the server might wish to cause the client to re-prompt the user for credentials.

• Applications that include a session termination indication (such as a "logout" or "commit" button on a page) after which the server side of the application "knows" that there is no further reason for the client to retain the credentials.

User agents that cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials under user control.

HTTP Authentication: Basic and Digest Access Authentication

Stack Overflow Questions:

• How to log out user from web site using BASIC authentication?
• How to clear basic authentication details in chrome
• http basic authentication “log out”
• How to logout user for basic HTTP authentication
• REST services basic auth session timeout
• Firefox quickly forget HTTP Basic Auth

Articles:

• Setting timeout for basic authentication
• Switch to basic authentication
• IIS authentication user timeout
• Basic Auth log-out with JavaScript
• Session timeout in Basic Authentication
• Saving HTTP Authentication?

Basics:

• What is the difference between "basic auth" and "form-based auth"?
• Compare and contrast the authentication types (BASIC, DIGEST, FORM, and CLIENT-CERT)
• Understanding IIS 7.0 Authentication