Research on http digest and persistent logins inorder to extend akc logins

You will find here research on http digest and persistent logins inorder to extend akc logins. See here how this theory is then used to implement. Implementation Details. See the most important references on this subject at the bottom of this page.

How to implement keep me logged in feature

Search for: How to implement keep me logged in feature

persistent login cookie best practice

Search for: persistent login cookie best practice

Here is an article to start the work

Implementing Remember me while logging in

Search for: Implementing Remember me while logging in

Here is a discussion on SOF

web authentication mechanisms

Search for: web authentication mechanisms

A discussion on authentication schemes at SOF

Here is a long discussion on various forms of security

HTTP basic authentication

Search for: HTTP basic authentication

Digest access authentication

Search for: Digest access authentication

Perhaps go to openid....

How to implement http digest authentication

Search for: How to implement http digest authentication

This is a good place to read on how to implement. See towards the end

what are the vulnerabilities of http digest

Search for: what are the vulnerabilities of http digest

This is a good read and a guideline for digest authentication from the rfc

yes!! Despite being an RFC, it is readable by humans! 


Password is encoded in base64 and sent to the server
Sniffers can convert this back to the password super easy
So password and userid is grabbed by sniffers

But I don't want to convert all my site to https as it will be slow and the information is not that super secret! My goal is not allow strangers access to the site that they delete or alter content!! 


password is encrypted through one-way-strong encryption
  like MD5
Sniffers can intercept but they don't know how to go back
  to the password
Server knows the password so it can calculate the MD5

However this doesn't prevent the replay or man in the middle attacks


Convert to digest first
Allow OpenID as a next improvement

Also see what information about the source machine is known to the server

I am thinking so because server can send a unique info to be encoded with the password. This unique info is different with each challenge. Investigate this property a bit more!!

Digest authentication and replay attacks

Search for: Digest authentication and replay attacks

Java Sample code for http digest

Search for: Java Sample code for http digest

Hope I fill find some, if not I will post soon here as I would be writing it in such a case...

Here appears to be some code listing

Understanding and implementing http digest authentication

Search for: Understanding and implementing http digest authentication

here is Sam Ruby on Nonce

A server-specified data string which should be uniquely generated each time a 401 response is made. It is recommended that this string be base64 or hexadecimal data. Specifically, since the string is passed in the header lines as a quoted string, the double-quote character is not allowed.

A string of data, specified by the server, which should be returned by the client unchanged in the Authorization header of subsequent requests with URIs in the same protection space. It is recommended that this string be base64 or hexadecimal data. 


//The following is calculated every X number of minutes
    public String calculateNonce() {
        Date d = new Date();
        SimpleDateFormat f = new SimpleDateFormat("yyyy:MM:dd:hh:mm:ss");
        String fmtDate = f.format(d);
        Random rand = new Random(100000);
        Integer randomInt = rand.nextInt();
        return DigestUtils.md5Hex(fmtDate + randomInt.toString());
    }


private String getOpaque(String domain, String nonce) {
        return DigestUtils.md5Hex(domain + nonce);
    }


private String getAuthenticateHeader() {
        String header = "";
 
        header += "Digest realm=\"" + realm + "\",";
        if (!StringUtils.isBlank(authMethod)) {
            header += "qop=" + authMethod + ",";
        }
        header += "nonce=\"" + nonce + "\",";
        header += "opaque=\"" + getOpaque(realm, nonce) + "\"";
 
        return header;
    }

The auth method is "auth" 


response.addHeader("WWW-Authenticate", getAuthenticateHeader());
response.sendError(HttpServletResponse.SC_UNAUTHORIZED);


auth: authentication
auth-int: authentication with integrity protection

Also note that if integrity protection is applied (qop=auth-int), the H(entity-body) is the hash of the entity body, not the message body - it is computed before any transfer encoding is applied by the sender and after it has been removed by the recipient. Note that this includes multipart boundaries and embedded headers in each part of any multipart content-type.

The"cnonce-value" is an optional client-chosen value whose purpose is to foil chosen plaintext attacks.

The "cnonce-value" and "nc-value" MUST be the ones for the client request to which this message is the response. The "response-auth", "cnonce", and "nonce-count" directives MUST BE present if "qop=auth" or "qop=auth-int" is specified.

With Digest authentication, a MITM or a malicious server canarbitrarily choose the nonce that the client will use to compute the response. This is called a "chosen plaintext" attack. The ability to choose the nonce is known to make cryptanalysis much easier

However, no way to analyze the MD5 one-way function used by Digest using chosen plaintext is currently known. The countermeasure against this attack is for clients to be configured to require the use of the optional "cnonce" directive; this allows the client to vary the input to the hash in a way not chosen by the attacker.

With Digest authentication, if the attacker can execute a chosen plaintext attack, the attacker can precompute the response for many common words to a nonce of its choice, and store a dictionary of (response, password) pairs. Such precomputation can often be done in parallel on many machines. It can then use the chosen plaintext attack to acquire a response corresponding to that challenge, and just look up the password in the dictionary. Even if most passwords are not in the dictionary, some might be. Since the attacker gets to pick the challenge, the cost of computing the response for each password on the list can be amortized over finding many passwords. A dictionary with 100 million password/response pairs would take about 3.2 gigabytes of disk storage.

The countermeasure against this attack is to for clients to be configured to require the use of the optional "cnonce" directive.

With Digest authentication, a MITM can execute a chosen plaintext attack, and can gather responses from many users to the same nonce. It can then find all the passwords within any subset of password space that would generate one of the nonce/response pairs in a single pass over that space. It also reduces the time to find the first password by a factor equal to the number of nonce/response pairs gathered. This search of the password space can often be done in parallel on many machines, and even a single machine can search large subsets of the password space very quickly -- reports exist of searching all passwords with six or fewer letters in a few hours.

The countermeasure against this attack is to for clients to be configured to require the use of the optional "cnonce" directive.

Note that the HTTP server does not actually need to know the user's cleartext password. As long as H(A1) is available to the server, the validity of an authorization header may be verified.

The Authorization header may be included preemptively; doing so improves server efficiency and avoids extra round trips for authentication challenges. The server may choose to accept the old Authorization header information, even though the nonce value included might not be fresh. Alternatively, the server may return a 401 response with a new nonce value, causing the client to retry the request; by specifying stale=TRUE with this response, the server tells the client to retry with the new nonce, but without prompting for a new username and password.

by specifying stale=TRUE with this response, the server tells the client to retry with the new nonce, but without prompting for a new username and password. 


HTTP/1.1 401 Unauthorized
         WWW-Authenticate: Digest
                 realm="[email protected]",
                 qop="auth,auth-int",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41"


Authorization: Digest username="Mufasa",
                 realm="[email protected]",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 uri="/dir/index.html",
                 qop=auth,
                 nc=00000001,
                 cnonce="0a4f113b",
                 response="6629fae49393a05397450978507c4ef1",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41"

username is available

realm is the same

returned nonce is the same

uri is returned

qop says just authentication and not integrity

**** nc = nonce count *** not sure how this is used

opaque is the same

***response is the calculated value based on the protocol***

See this url on how the response is calculated

what is nonce count used for?

Search for: what is nonce count used for?

A good discussion on nonce count

The nc-value is the hexadecimal count of the number of requests (including the current request)that the client has sent with the nonce value in this request. For example, in the first request sent in response to a given nonce value, the client sends "nc=00000001". The purpose of this directive is to allow the server to detect request replays by maintaining its own copy of this count - if the same nc-value is seen twice, then the request is a replay. 


ha1 = md5(username:realm:password)
ha2 = md5(method:digestURI) //for qop=auth or none
ha2 = md5(method:digestURI:md5(body)) //for auth-int


//auth or auth-int
response = md5(ha1 : nonce : nonceCount : clientNonce: qop : HA2)

//for empty qop
response = md5(ha1 : nonce : ha2)

In http digest what is Opaque used for?

Search for: In http digest what is Opaque used for?

Here is some discussion on the subject

and http being a stateless protocol, you can use this field to carry state information or the context in which this is sent. 


nonce
client nonce
nonce count
qop
auth
auth-int
opaque

what is etag header

Search for: what is etag header

here is what etags are

An implementation might choose not to accept a previously used nonce or a previously used digest, in order to protect against a replay attack. Or, an implementation might choose to use one-time nonces or digests for POST or PUT requests and a time-stamp for GET requests.

As shown in the example nonce in section 3.2.1, the server is free to construct the nonce such that it may only be used from a particular client, for a particular resource, for a limited period of time or number of uses, or any other restrictions. Doing so strengthens the protection provided against, for example, replay attacks

varying nonce by ip address

Search for: varying nonce by ip address

Design of a good nonce

Search for: Design of a good nonce

Here is some discussion on it

Here is an attempt by one that went before...

adding a sessionid to the http digest nonce

Search for: adding a sessionid to the http digest nonce

http digest and a strong nonce

Search for: http digest and a strong nonce

stack over flow nonce

Search for: stack over flow nonce

Note: including the IP address of the client in the nonce would appear to offer the server the ability to limit the reuse of the nonce to the same client that originally got it. However, that would break proxy farms, where requests from a singleuser often go through different proxies in the farm. Also, IP address spoofing is not that hard.

How best to vary the nonce to stop a replay attack

Search for: How best to vary the nonce to stop a replay attack

what is http session hijacking

Search for: what is http session hijacking

On Session hijacking

Commons codec download page

how to use md5 from jdk 1.6

Search for: how to use md5 from jdk 1.6

Here is a good discussion from sof

getting a cookie from httpservletrequest

Search for: getting a cookie from httpservletrequest


/**
   **************************************************************
   * getCookie
   **************************************************************
   */
  public static Cookie getCookie(String cookieName, HttpServletRequest request)
  {
     Cookie[] carray = request.getCookies();
     for(Cookie c: carray)
     {
        if (c.getName().equals(cookieName))
        {
           return c;
        }
     }
     return null;
  }

API docs on j2ee cookies

expiry - an integer specifying the maximum age of the cookie in seconds; if negative, means the cookie is not stored; if zero, deletes the cookie

By default this is -1, meaning it will go away when the browser exits. 


private void setRLKCookie(HttpServletResponse response, String rlk)
   {
       //set the cookie on the response
      AppObjects.info(this, "Setting RLK cookie: %1s", rlk);
      
      //Create a 3 month cookie
      Cookie pc = new Cookie(RLK_COOKIE_NAME,rlk);
      
      int m3 = 3 * 30 * 24 * 60 * 60;
      pc.setMaxAge(m3);
      response.addCookie(pc);
   }

it is captured here not to forget and not for completeness or accuracy!

Acknowledgements and Key References

1) A quick read on what digest authentication is. This introuductory document is useful as a quick reference for how the various parts of http digest is calculated. Introduces such things as nonce, cnonce etc and lays out the formulas in a concise manner.

2) Http Digest RFC 2617. Http Digest RFC 2617 this is actually readable. Probably a must read before you complete your implementation. Talks about various attacks and how each piece of the http digest tries to address. It is a bit tough to read through but an essential and once you get it, it is a great read!

3) The definitive guide to web site authentication schemes at Stack Over Flow

4) A discussion at SOF on variious auth schemes

5) Munir Usamas sample code for Http Digest for J2EE. This was an invaluable resource for me. I have borrowed most of my code from here. Many many thanks to Munir Usama.

6) Apace Commons Codec: Required for generating MD5 digests. Munir's code uses this library if you intend to borrow his code like I did.

7) J2EE documentation on working with Cookies

8) http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/ . Persistent Login Cookie Best Practice by Charles Miller. This appears to be the most referenced document on the the subject of persistent logins

9) Here is a related dicussion at Stack Over Flow on Persistent Logins