REST HMAC/digest support

[set321go <sw...@hotmail.com>]

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.

Re: REST HMAC/digest support

[Les Hazlewood <lh...@apache.org>]

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 <sw...@hotmail.com> 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.
>