In my view - supporting OAuth MAC Token Profile [1] is high priority than this...
[1]: https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05 Thanks & regards, -Prabath On Wed, Sep 2, 2015 at 1:02 PM, Prabath Siriwardena <[email protected]> wrote: > 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 > -- 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
