
How we overcame the security flaws of performing REST API calls in JavaScript - redox_
http://blog.algolia.com/handle-security-realtime-search/
======
tptacek
Um, eek?

You can't safely use SHA256 in that construction. The hash is simply the value
of the SHA256 internal state after the last block. An attacker can take that
hash and resume "hashing" from that point, adding additional data to the
original data.

That attack is called "length extension", and it's the reason we have the HMAC
construction. Here, I think you want the HMAC-SHA256 of the filter and user
ID, with the API key as the HMAC key.

~~~
redox_
Thanks for the feedback guys, gonna edit the blog post and update our code.
Having security gurus reading us is definitely a strength of HN!

------
tantalor
I suggest you investigate oAuth instead of rolling something yourself. That's
how Google, Facebook, and Twitter solve this problem. Pick whichever version
suits your needs,

[http://oauth.net/core/1.0a/](http://oauth.net/core/1.0a/) (2009)

[http://oauth.net/2/](http://oauth.net/2/) (2012)

~~~
jlemoine
We care a lot about the simplicity of our API. oauth adds too much complexity
and does not fit well our use case (we don't need authentication).

~~~
dmak
You don't need to authenticate. You can use OAuth for just authorization:
[http://tools.ietf.org/html/rfc6749#section-1.3.2](http://tools.ietf.org/html/rfc6749#section-1.3.2)

~~~
jlemoine
But this would reduce the ease of use of the API, increase the latency because
of round-trip and will not provide a better security. The fit is not very
good.

oauth is a good standard when used for the correct use case, which is not the
case for this. Sometime a simple solution is better than a framework

------
woah
I just use the normal cookie sessions over HTTPS. Rolling your own encryption
just seems like a bad idea, and I don't understand why people do it.

------
geoka9
I'd say that's what OAuth2, with its scoped access tokens, was made for.

------
lsh123
Sounds like this is not an _authentication_ but an _identification_ protocol
applied for a very limited API calls rate-limiting use case. While there are
some question about this use case as well (e.g. it there is a DOS attack
possible against legitimate clients if the secured_api_key is leaked), it
might be practical and acceptable in some limited set of cases.

The danger here is that the same protocol will be used for access control use
cases for which it is not suitable (for a variety of reasons). A very good
documentation (including thread modeling with attack vectors analysis) should
be added to make sure this kind of mis-use does not occur. I would also change
the title since it is too ambitious and misleading.

------
flakmonkey
Sounds like you've implemented a type of JWT: [http://openid.net/specs/draft-
jones-json-web-token-07.html](http://openid.net/specs/draft-jones-json-web-
token-07.html)

~~~
arethuza
It does seem a bit odd - they say:

"Our backend checks if a query is legit by computing all the possible hashes
using all your available API keys"

So why not just forget about the crypto (with all the risks of getting it
wrong) and use an opaque bearer token?

~~~
Xylakant
If you want to validate a bearer token, multiple backends in different
datacenters need to share a datastore that replicates at least somewhat fast.
If you use HMAC-Signed URLS you just need to replicate the API keys that you
use to calculate the token and the required guarantees are lower than for a
bearer token. In principle, the method is sound - AWS uses a similar approach
for signed URLs that allow access to S3 resources.

~~~
arethuza
Yes - that makes sense - thanks.

I guess it's a question of where do you store application state - do it at the
server and then you have to replicate the database that stores that state.
Store session state at the client and pass it to the server means you can go
to any data center at the potential risk of getting the security wrong.

------
dmak
This is what the implicit grant is for in OAuth:
[http://tools.ietf.org/html/rfc6749#section-1.3.2](http://tools.ietf.org/html/rfc6749#section-1.3.2)

------
joncalhoun
I believe Keen.io does something very similar to this as well. iirc they use
hashed API keys with some user ID in order to show user specific metrics.

I always thought there approach was interesting. Kudos for coming up with
something very similar.

------
hernan604
read about: SHA1 HMAC

------
kcbanner
Uh oh

