

Getting started with designing a Secure REST (Web) API - nait
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

======
tptacek
_A client creates a unique HMAC (hash) representing it’s request to the
server_

 _[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.

------
icebraining
_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.

------
pelle
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.

<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...](http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05)

Both of them are still officially drafts, but are mainly receiving wording
changes now. I'd say they are both ready for primetime.

------
arethuza
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].

~~~
weavejester
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.

~~~
arethuza
Good point about curl - a strong motivation of mine was to make the API easy
to access through tools like curl.

[I have seen some discussions about adding explicit support for OAuth in curl]

------
alexchamberlain
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.

~~~
abhaga
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.

~~~
steverb
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.

We (developers) do love re-inventing wheels.

~~~
loganfrederick
Do you have any recommended tutorials/walkthroughs for building a REST API?

~~~
icebraining
<http://shop.oreilly.com/product/9780596529260.do>

------
smuggyuk
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.

