- 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].
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
16 comments
[ 5.1 ms ] story [ 57.0 ms ] thread- 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.
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.
[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.