Joyent unveils HTTP Signature auth scheme for REST APIs
1–10 of 11 posts
Re: Joyent unveils HTTP Signature auth scheme for REST APIs
#2Having 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.
Re: Joyent unveils HTTP Signature auth scheme for REST APIs
#3They're not unveiling anything. They're just describing how their API works, and they've reinvented a wheel.
Re: Joyent unveils HTTP Signature auth scheme for REST APIs
#4As 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.
Re: Joyent unveils HTTP Signature auth scheme for REST APIs
#5As 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.
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.
Re: Joyent unveils HTTP Signature auth scheme for REST APIs
#6As 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.
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.
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.
Re: Joyent unveils HTTP Signature auth scheme for REST APIs
#7A better write-up can be found on GitHub: https://github.com/joyent/node-http-signature/blob/master/ht...
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.
Re: Joyent unveils HTTP Signature auth scheme for REST APIs
#8I 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)
Re: Joyent unveils HTTP Signature auth scheme for REST APIs
#9Having 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…
How do your alternative examples solve the problem of using a single key (ssh key) to authenticate both using an ssh client and http(s)?
Re: Joyent unveils HTTP Signature auth scheme for REST APIs
#10They're not unveiling anything. They're just describing how their API works, and they've reinvented a wheel.
What other authentication scheme combines HTTP(S) and SSH keys in a similar way?