HMAC isn't a hash. It's not interchangeable with a hash. HMAC is a MAC. If you try to use a standard hash function to create a MAC, it will blow up in your face. This article is not good, in multiple ways; you should disregard it.
Re:Getting started with designing a Secure REST (Web) API
by icebraining on Thursday February 16, 2012 @08:27AM
(#3598472)
You realize that hashing the password and sending the hash over the wire in lieu of the plain-text password still gives people sniffing at least the username for the account and a hash of the password that could (in a disturbing number of cases) be looked up in a Rainbow Table.
No. Getting the username and cracking the hash is the least of your concerns. The problem of just hashing the password and sending it over an unsecured channel is that you're vulnerable to replay attacks: the attacker doesn't need to crack it, just re-send the hash. Essentially, the hash becomes a plain-text password.
Re:Getting started with designing a Secure REST (Web) API
by pelle on Thursday February 16, 2012 @08:55AM
(#3598564)
When it comes to security please do not try to hack together your own thing it rarely ends up well.
People still think OAuth is complicated. OAuth 1 was very complicated and caused untold issues for implementers who didn't use libraries and for those of us who maintained libraries who to this day tell us that our proven libraries implement things wrong.
OAuth 1.0 should not be used for any new applications. OAuth is dead long live OAuth(2).
OAuth 2 is essentially ready to be used, but unless you need to deal with token issuance and delegated access you don't even need that.
If all you need is an API token over SSL then use the Bearer Token spec is what most people call OAuth 2 and is just a single token in a http header or query string. It is incredibly easy to implement and you don't even need a library.
More complex but if for some reason you don't want to use SSL or if you need to share url's similar to Amazons signed urls where you need to give some access to a resource such as an image or download use the Mac token, which is receiving serious security analysis now:
Re:Getting started with designing a Secure REST (Web) API
by arethuza on Thursday February 16, 2012 @06:58AM
(#3598252)
What's wrong with an approach of:
- For client access to a server, use basic auth over HTTPS
- For client/server to server access, use OAuth
Note - I'm genuinely interested what people think as I'm just finishing off a personal project using a RESTful interface and this is the approach I have used so far.
[Edited based on comment - and I should point out that I haven't implemented OAuth yet but I should really check out how it would work].
Re:Getting started with designing a Secure REST (Web) API
by weavejester on Thursday February 16, 2012 @08:23AM
(#3598455)
It provides an additional layer of security over HTTPS/BasicAuth, so if your SSL certificate or even the CA is compromised, you retain a degree of security.
On the other hand, it makes it more difficult for developers to access your API; you can't just send requests over Curl, for instance.
Re:Getting started with designing a Secure REST (Web) API
by alexchamberlain on Thursday February 16, 2012 @07:09AM
(#3598277)
I didn't read this for one simple reason - the dismissal of OAuth as complex. It's not that bad and it is secure. It's proven secure by experts and open source libraries exist.
Re:Getting started with designing a Secure REST (Web) API
by abhaga on Thursday February 16, 2012 @07:24AM
(#3598314)
His solution turns out to be close to OAuth 2.0 in the end, so you are right. But I liked the article because it walks you through the thought process of someone trying to do it on their own. This understanding of all the small things you may end up ignoring in your own efforts actually makes a stronger case for OAuth then believing an expert's words.
Re:Getting started with designing a Secure REST (Web) API
by steverb on Thursday February 16, 2012 @08:19AM
(#3598443)
Actually, it was basically 2-Legged OAuth 1. I was shaking my head all the way through the article, having gone through the same process about a year and a half ago.
Re:Getting started with designing a Secure REST (Web) API
by tfb on Thursday February 16, 2012 @09:06AM
(#3598613)
When I need to learn about a wheel, I usually attempt to re-invent it. But in practice (production), I tend to choose a wheel that someone else has already spent years making perfectly round.
What is learned from re-inventing definitely provides unique insight into how the better wheels are actually spinning and ultimately helps us make better use of it.
Re:Getting started with designing a Secure REST (Web) API
by alexchamberlain on Thursday February 16, 2012 @09:40AM
(#3598824)
I'm not saying that we should all use OAuth 2.0 without due understanding, but we should all admit that we're not all experts at everything, and sometimes we should bow to peer reviewed knowledge.
Re:Getting started with designing a Secure REST (Web) API
by smuggyuk on Thursday February 16, 2012 @05:50PM
(#3601078)
Does anyone have any comments on protecting the private key / API in an unsecure client (such as Javascript, or a mobile app where the source code can be readily viewed)? He mentions it in this article, but no one seems to address it in the comments and the solution offered of "reset the private key" doesn't seem terribly secure.
[CLIENT] Hash (HMAC-SHA1 or SHA256 preferably) the blob of data data (from Step #1) with your private key assigned to you by the system.
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!
HMAC isn't a hash. It's not interchangeable with a hash. HMAC is a MAC. If you try to use a standard hash function to create a MAC, it will blow up in your face. This article is not good, in multiple ways; you should disregard it.
No. Getting the username and cracking the hash is the least of your concerns. The problem of just hashing the password and sending it over an unsecured channel is that you're vulnerable to replay attacks: the attacker doesn't need to crack it, just re-send the hash. Essentially, the hash becomes a plain-text password.
People still think OAuth is complicated. OAuth 1 was very complicated and caused untold issues for implementers who didn't use libraries and for those of us who maintained libraries who to this day tell us that our proven libraries implement things wrong.
OAuth 1.0 should not be used for any new applications. OAuth is dead long live OAuth(2).
OAuth 2 is essentially ready to be used, but unless you need to deal with token issuance and delegated access you don't even need that.
If all you need is an API token over SSL then use the Bearer Token spec is what most people call OAuth 2 and is just a single token in a http header or query string. It is incredibly easy to implement and you don't even need a library.
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16
More complex but if for some reason you don't want to use SSL or if you need to share url's similar to Amazons signed urls where you need to give some access to a resource such as an image or download use the Mac token, which is receiving serious security analysis now:
http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-0...
Both of them are still officially drafts, but are mainly receiving wording changes now. I'd say they are both ready for primetime.
- For client access to a server, use basic auth over HTTPS
- For client/server to server access, use OAuth
Note - I'm genuinely interested what people think as I'm just finishing off a personal project using a RESTful interface and this is the approach I have used so far.
[Edited based on comment - and I should point out that I haven't implemented OAuth yet but I should really check out how it would work].
On the other hand, it makes it more difficult for developers to access your API; you can't just send requests over Curl, for instance.
[I have seen some discussions about adding explicit support for OAuth in curl]
We (developers) do love re-inventing wheels.
What is learned from re-inventing definitely provides unique insight into how the better wheels are actually spinning and ultimately helps us make better use of it.