How we overcame the security flaws of performing REST API calls in JavaScript(blog.algolia.com)
blog.algolia.com
How we overcame the security flaws of performing REST API calls in JavaScript
http://blog.algolia.com/handle-security-realtime-search/
11 comments
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!
Almost funny: not recognizing the need to apply "simple" HMAC but yea we found a secure way to XYZ... eeeek indeed ;)
Time again and again and again: never ever implement your own crypto...
Time again and again and again: never ever implement your own crypto...
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/ (2009)
http://oauth.net/2/ (2012)
http://oauth.net/core/1.0a/ (2009)
http://oauth.net/2/ (2012)
Out of all of these, I've always found the HMAC hashed request in OAuth 1 to make the most sense from a basic security point of view. The only concern being token refreshes.
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).
You don't need to authenticate. You can use OAuth for just authorization: http://tools.ietf.org/html/rfc6749#section-1.3.2
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
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
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.
I'd say that's what OAuth2, with its scoped access tokens, was made for.
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.
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.
Sounds like you've implemented a type of JWT: http://openid.net/specs/draft-jones-json-web-token-07.html
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?
"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?
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.
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.
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.
This is what the implicit grant is for in OAuth: http://tools.ietf.org/html/rfc6749#section-1.3.2
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.
I always thought there approach was interesting. Kudos for coming up with something very similar.
read about: SHA1 HMAC
Uh oh
[deleted]
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.