

Joyent unveils HTTP Signature auth scheme for REST APIs - harrylove
http://joyeur.com/2012/01/03/a-bit-more-about-the-new-joyent-cloud-api/

======
pquerna
Having yet another HTTP Authentication and Signature scheme really isn't
adding value to the world.

It's too bad this couldn't model the Keystone token authentication API that
OpenStack is doing:

<http://keystone.openstack.org/>

Or say, heck, don't like OpenStack, even just using OAuth2 would be fine:

<http://datatracker.ietf.org/wg/oauth/charter/>

It sounds cool, using SSH keys as your API signature, but really it isn't
solving a problem that hasn't already been solved.

~~~
mcavage
We didn't want token-based auth (i.e, Oauth2 or openstack), nor did we want
shared-secret based auth (i.e., hmac). We specifically wanted to offer
authentication with public-key crypto, and as the blog post points out, the
usability of client-auth SSL sucks.

So when you say it's not solving a problem that hasn't already been solved, if
you're talking about "the ability to sign a request" in the most generic
sense, sure, it's already been solved N times.

Generally speaking though, in most of those schemes key management is an
afterthought, and we didn't want it to be an afterthought. It's been solved by
SSH, and that's what we wanted to leverage.; the point was not to reinvent the
wheel, the point was to leverage an existing security mechanism.

------
spoondan
A better write-up can be found on GitHub: [https://github.com/joyent/node-
http-signature/blob/master/ht...](https://github.com/joyent/node-http-
signature/blob/master/http_signing.md)

Frankly, the blog post leaves a lot of questions and is short on links to
answers. It would be easy to walk away from the post thinking Joyent's HTTP
Signatures to be incompetently designed. It was almost enough to have me quip,
"More like HTTPS Signatures," because the design in the blog post is only
sensible over TLS. However, having found the above link, I see that it is the
defaults that assume TLS, but that you can specify the signature contain all
headers and the request line. This makes it possible to sign requests over
HTTP.

I'd rather the defaults be reasonable for insecure transports (i.e., all
headers + 'request-line'), since the TLS case is easily handled with just
'headers="date"'. If that's not to happen, I'd hope that implementations
actively prevent the use of the defaults over insecure transports.
Unfortunately, Joyent's reference implementation doesn't seem to do this.

------
foobarbazetc
They're not unveiling anything. They're just describing how their API works,
and they've reinvented a wheel.

~~~
thu
What other authentication scheme combines HTTP(S) and SSH keys in a similar
way?

------
justinsb
I really like the idea of using SSH keys: one less password to manage, and it
avoids sharing a secret with your provider.

With hash-based signature schemes, you know that your secret has to be stored
in cleartext, which is why you can't choose your own signing token on any
clouds.

As a solution for technical users, SSH-keys seem like a great idea: they're
battle-tested, avoid a shared secret, are no less convenient than using long
system-generated tokens, and have a much richer ecosystem (e.g. ssh-agent,
password protection, the possibility to store it on hardware devices etc)

------
bromley
As far as I can tell the signature applies only to the date header. Which
means that if an attacker can intercept a signed request they can swap in any
request of their own without having to change the signature at all. And the
server will interpret it as a legitimate signed request.

~~~
pquerna
They are using TLS to assume that the client authenticates the server is who
it says it is -- if you can man in the middle TLS, there are lots of other
possible exploits besides this signature one.

~~~
bromley
Thanks. It's not clear to me from the post that it's using TLS but that would
make sense. Though if requiring TLS I wonder why not just use basic auth since
it's simpler and since TLS would protect the password.

One of the things that's neat about, say, OAuth's MAC authentication, is that
it works over plain old HTTP without TLS. Likewise for the AWS API's
signature-based security scheme. Sounds like I erroneously assumed that this
was aiming to do similarly.

