Hiya, 1. HMACs are 'keyed-hash cryptographic hash functions': this means they take some data along with a cryptographic secret key (e.g. a password), and the output is a digest (aka 'hash'). Sometimes people call this a 'pasword-based hash' to help visualize what is going on.
And yes, the nice thing about HMACs is that the resulting output is sent across the wire - not the secret password. The server that receives an hmac digest in a request is expected to know that same raw secret password. When it receives the request, it computes the exact same digest (using the same algorithm). If the digest the server computes matches the same digest sent in the request, then the request can reasonably be assumed to be authentic. Digest based authentication schemes like OAuth1.0a and Stormpath's own custom scheme [1] have the benefit that the password is never transmitted - only the digest - making it a pretty secure authentication technique. Also, because it is a digest, it has the added benefit of ensuring that the data used to compute the digest hasn't been tampered in any way (otherwise the digest computed by the server would be different and fail the check). Add in SSL and you have a very secure authentication protocol. I expanded on this in a StackOverflow question a while ago - hopefully this helps: http://stackoverflow.com/questions/14043397/http-basic-authentication-instead-of-tls-client-certificaiton/14046557#14046557 I *strongly* recommend that you do *not* attempt to design your own digest authentication protocol. Use OAuth1.0 or at the least, copy Stormpath's or Amazon's. Getting even a small part of the algorithm wrong can seriously compromise authentication. 2. The requirements for the content to hash is the tricky part of designing a digest authentication protocol. If you're curious of what might be involved, you can see Stormpath's [1]. Stormpath's takes into account many things when computing the digest: timestamp, headers, request path, query string, request body, nonce, etc and also uses a key derivation function. Each of these things must be organized/aligned in the exact same way on the client and the server to ensure the algorithm is the same. This means that if you're not using a standard protocol like OAuth1.0a, you're putting a tremendous expectation on your REST API callers to re-create the algorithm (most REST callers are not crypto experts and would be frustrated by this quickly). Stormpath for example supports its custom scheme primarily because we distribute multiple language SDKs that our customers can just use. We write each SDK and each implementation of the algorithm across Java, Ruby, PHP, Python, etc. If we asked our customers to implement the algorithm themselves, they'd never use us. For customers that can't use one of our SDKs, we support other common authentication schemes that they are expected to be able to use. In any event, there are no 'requirements' as to what to take into account - that is up to you. Stormpath for example takes into account as much as we can. The more that you can ingest into the hash function, the more you can rest assured that those things have not been tampered with or forged. This part is up to you. But again, if you get it wrong, you could have some serious problems. I'd just use Stormpath's or Amazon's. Better yet, just save yourself a lot of effort and use OAuth1.0a so your clients can integrate with you with existing OAuth1.0a client libraries (so you don't have to write them yourself). [1] https://github.com/stormpath/stormpath-sdk-java/blob/master/impl/src/main/java/com/stormpath/sdk/impl/http/authc/Sauthc1Signer.java -- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 On Mon, Apr 15, 2013 at 10:12 PM, set321go <[email protected]> wrote: > Hello, > > I have used shiro for a couple of projects now, I generally reuse a > AuthorizingRealm that implements salting and multiple hash iterations but I > would like to build a filter that can authenticate rest access. > > Ideally the user would use an inline form on the page to authenticate and > some kind of hash would be used in each subsequent request to verify the > user. > > From what I can see in the tracker and the forum there seems to have been > some investigation into implementing something a while ago but nothing > seems > to have materialised, so... > > I have tried to understand HMAC (I read the wiki page and the rfc!) but I > still have a few questions. > > 1. The users password, from what I gather this is never transmitted over > the > wire (assuming the user already exists on the server)? > 2. What are the requirements on what should be in the content portion used > to generate the hash? message body, url, timestamp? > > > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/REST-HMAC-digest-support-tp7578584.html > Sent from the Shiro User mailing list archive at Nabble.com. >
