satya - 6/4/2013 9:47:34 AM
here is an image to understand this early on that i drew
it is captured here not to forget and not for completeness or accuracy!
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.
satya - 5/15/2013 3:35:29 PM
How to implement keep me logged in feature
How to implement keep me logged in feature
satya - 5/15/2013 3:37:10 PM
persistent login cookie best practice
persistent login cookie best practice
satya - 5/15/2013 3:37:38 PM
Here is an article to start the work
satya - 5/15/2013 3:38:13 PM
Implementing Remember me while logging in
Implementing Remember me while logging in
satya - 5/16/2013 10:15:49 AM
web authentication mechanisms
web authentication mechanisms
satya - 5/16/2013 10:17:48 AM
A discussion on authentication schemes at SOF
satya - 5/16/2013 10:29:56 AM
Here is a long discussion on various forms of security
satya - 5/16/2013 10:47:46 AM
HTTP basic authentication
HTTP basic authentication
satya - 5/16/2013 10:56:48 AM
Digest access authentication
Digest access authentication
satya - 5/16/2013 11:02:27 AM
Perhaps go to openid....
Perhaps go to openid....
satya - 5/16/2013 11:02:52 AM
How to implement http digest authentication
How to implement http digest authentication
satya - 5/16/2013 11:06:56 AM
This is a good place to read on how to implement. See towards the end
This is a good place to read on how to implement. See towards the end
satya - 5/16/2013 11:28:53 AM
what are the vulnerabilities of http digest
what are the vulnerabilities of http digest
satya - 5/16/2013 11:33:59 AM
This is a good read and a guideline for digest authentication from the rfc
This is a good read and a guideline for digest authentication from the rfc
yes!! Despite being an RFC, it is readable by humans!
satya - 5/16/2013 2:44:57 PM
Vulnerabilities of Http Basic Auth
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
satya - 5/16/2013 2:46:18 PM
That is assuming HTTP and not HTTPS
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!!
satya - 5/16/2013 2:48:03 PM
Http Digest vulnerabilities
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
satya - 5/16/2013 2:48:24 PM
So my approach
Convert to digest first
Allow OpenID as a next improvement
satya - 5/16/2013 2:51:15 PM
Also see what information about the source machine is known to the server
Also see what information about the source machine is known to the server
satya - 5/16/2013 2:53:42 PM
I believe digest prevents from using the same token reused
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!!
satya - 5/16/2013 2:54:00 PM
Digest authentication and replay attacks
Digest authentication and replay attacks
satya - 5/16/2013 4:24:18 PM
Java Sample code for http digest
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...
satya - 5/16/2013 4:25:57 PM
Here appears to be some code listing
satya - 5/17/2013 9:38:36 AM
Understanding and implementing http digest authentication
Understanding and implementing http digest authentication
Search for: Understanding and implementing http digest authentication
satya - 5/17/2013 11:03:41 AM
From the rfp link above A Nonce is
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.
satya - 5/17/2013 11:06:14 AM
Opaque
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.
satya - 5/17/2013 11:08:48 AM
Here is how one Nonce is calculated from the code above
//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());
}
satya - 5/17/2013 11:09:27 AM
Here is how Opaque is calculated in the code above again
private String getOpaque(String domain, String nonce) {
return DigestUtils.md5Hex(domain + nonce);
}
satya - 5/17/2013 11:10:44 AM
Here is how the request header is constructed
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"
satya - 5/17/2013 11:11:42 AM
Here is how you prime the response to challenge for a password
response.addHeader("WWW-Authenticate", getAuthenticateHeader());
response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
satya - 5/17/2013 11:25:37 AM
qop means quality of protection. It has 2 values
auth: authentication
auth-int: authentication with integrity protection
satya - 5/17/2013 11:28:41 AM
Here is what happens if you set 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.
satya - 5/17/2013 12:15:44 PM
Understanding cnonce
The"cnonce-value" is an optional client-chosen value whose purpose is to foil chosen plaintext attacks.
satya - 5/17/2013 12:32:14 PM
More on cnonce
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.
satya - 5/17/2013 12:33:53 PM
passwords
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.
satya - 5/17/2013 12:35:32 PM
The Authorization header may be included preemptively
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.
satya - 5/17/2013 12:36:44 PM
Stale=true
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.
satya - 5/17/2013 12:40:43 PM
Here is a server challenge
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="testrealm@host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
satya - 5/17/2013 12:41:02 PM
And the response from the client
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
satya - 5/17/2013 12:43:39 PM
lets notice a couple of things
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***
satya - 5/17/2013 12:50:26 PM
See this url on how the response is calculated
satya - 5/17/2013 12:50:51 PM
what is nonce count used for?
what is nonce count used for?
satya - 5/17/2013 12:58:50 PM
More 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.
satya - 5/17/2013 1:06:30 PM
Ok the rules for MD5 and not MD5-sess
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)
satya - 5/17/2013 1:17:27 PM
In http digest what is Opaque used for?
In http digest what is Opaque used for?
satya - 5/17/2013 1:19:34 PM
Here is some discussion on the subject
satya - 5/17/2013 1:21:12 PM
Because it comes back as it was sent....
and http being a stateless protocol, you can use this field to carry state information or the context in which this is sent.
- 5/17/2013 1:22:14 PM
Here are the weird things that I know more off now...
nonce
client nonce
nonce count
qop
auth
auth-int
opaque
annonymous - 5/17/2013 1:33:24 PM
what is etag header
what is etag header
annonymous - 5/17/2013 1:51:45 PM
Revisiting nonce
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.
annonymous - 5/17/2013 1:55:39 PM
More...
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
annonymous - 5/17/2013 2:03:47 PM
varying nonce by ip address
varying nonce by ip address
Satya - 5/17/2013 2:06:48 PM
Design of a good nonce
Design of a good nonce
Satya - 5/17/2013 2:10:58 PM
Here is an attempt by one that went before...
Satya - 5/17/2013 2:15:27 PM
adding a sessionid to the http digest nonce
adding a sessionid to the http digest nonce
Satya - 5/17/2013 2:22:17 PM
http digest and a strong nonce
http digest and a strong nonce
Satya - 5/17/2013 2:23:32 PM
stack over flow nonce
stack over flow nonce
Satya - 5/17/2013 2:29:52 PM
Here is why not use ip for nonces, again from the RFC
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.
Satya - 5/17/2013 2:38:03 PM
How best to vary the nonce to stop a replay attack
How best to vary the nonce to stop a replay attack
Search for: How best to vary the nonce to stop a replay attack
Satya - 5/17/2013 3:10:18 PM
what is http session hijacking
what is http session hijacking
satya - 5/22/2013 4:36:53 PM
how to use md5 from jdk 1.6
how to use md5 from jdk 1.6
satya - 5/24/2013 1:33:00 PM
getting a cookie from httpservletrequest
getting a cookie from httpservletrequest
satya - 5/24/2013 1:48:33 PM
an example
/**
**************************************************************
* 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;
}
satya - 5/24/2013 3:18:48 PM
max age
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.
satya - 5/24/2013 3:21:56 PM
an example
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);
}
satya - 6/4/2013 9:47:34 AM
here is an image to understand this early on that i drew
it is captured here not to forget and not for completeness or accuracy!
satya - 6/4/2013 9:48:15 AM
Here is a continuation of that thought
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