I guess you are talking about the HTTP Digest Authentication as in RFC 2617.
The challenge in digest auth is the user store should store passwords in cleartext (or encrypted - but not hashed) or should store the hash value of username:password:realm. Thanks & regards, -Prabath On Wed, Sep 2, 2015 at 12:27 AM, Tharika Madurapperuma <[email protected]> wrote: > Hi All, > > We currently have Basic auth to support secure endpoints in API > Manager. We hope to provide a "Digest auth facility" as well, in our next > release 1.10, in order to ensure better security. > > In this feature, the client(The API Developer) will have the > ability to select the authentication type he or she requires as either > Basic auth or Digest auth. > > If the client selects Digest auth as the preferred authentication > type, the password is never sent over the network in plain text whenever > the client requests access to a resource. What we send is only a hash. > > The following diagram explains the digest authentication process in a > nut shell. > > > > > I will further explain it here. > > 1. The client sends a request to the backend for accessing the resource. > > 2. The backend receives the request and sends back a 401 Authentication > required message indicating that the client’s request has generated an > unauthorized access error. > > 3. Then the client extracts the required information from the message sent > by the backend and generates hashes as shown by the source code below. > > HA1 = md5(username:realm:password) > HA2 = md5(requestMethod:uri) > Hash = md5(HA1:serverNonce:nc:cnonce:qop:HA2) > > The * realm* is a string which is used as part of the hash. It is the > name of the domain that contains the account indicated by the user name. > > The *qop*(Quality Of Protection) can be one of auth, auth-int etc. and > has influence on how the hash is created. We use auth here. > > The *serverNonce* is a unique code, which is used within the hash and > needs to be sent back by the client to the backend. > > The above are the essential information gathered from the 401 response > sent by the backend. > > Then the *username* and the *password* supplied by the client, the realm, > the serverNonce and the qop sent by the backend are used for the creation > of the hash along with the following as well. > > The *nc* is the Nounce count which is a hexadecimal serial number for the > request. The client should increase this number by one for every request. > It is the number of times the client has sent a challenge response by using > the nonce. The nonce must be specified if a "qop" directive is sent. > > The * cnonce* is a unique id generated by the client. This nonce > represents a challenge issued by the client to the server when immediate > authentication of the server is desired. It can also be used to chosen > plain text attacks. > > The *uri* is the authentication uri of the requested resource and the *request > method* can be one of GET, POST, etc. > > 4. The final Hash generated here is then sent to the backend for > authentication, incorporated in an authentication header along with the > following content. > > The username, realm, serverNonce, uri, qop, nc and cnonce. Note that the > password is not sent along with these information. > > 5. Then the backend will respond accordingly with respect to the validity > of the authentication. > > The hash cannot be decrypted. Therefore the backend does this check by > applying the same hashing procedure with the password stored in the > database of the backend. If the hashes match, access is granted to the > requested resource. > > > Tharika Madurapperuma > Software Engineering Intern > WSO2 > Mobile : +94777-875-624 > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://blog.facilelogin.com http://blog.api-security.org
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
