For anyone that kept seeing "HMAC" and thought "What in the hell..." I wrote an article (stream of thought in story format) describing how you might try and secure an API call, how AWS does it and eventually how 2-legged OAuth can be utilized to do it:
NOTE: This is written from the perspective of "My god, what does this all mean?"
NOTE #2: You can do away with almost ALL of this complexity if you just force everyone onto SSL connections, but then you have to be ok with the increased latency introduced connection-(re)negotiation; just depends on what your API needs to do.
NOTE #3: I think the title of this article is misleading... there is no security on an untrusted client using HMAC -- if your client knows your secret AND they are untrusted, then you have problems.
I wasn't clear from the article how the JS library running client side is adding the secret to the digest before sending the request to the server to verify and process.
For those AWS folks out there, that is what your AWS secret is used for -- your request, e.g.:
/ec2/launch?cust=bdillon&size=xl&quant=2&sig=akjDjlasdmnDASkljasd
to sign the entire request, so when AWS receives the request, the first thing it does is attempt to re-create the exact same signature using the secret it has on file for "bdillon" (or whatever customer-identifying info was sent)
This requires both the caller and server to know the secret and I am not clear on how filepicker is solving this from this article... very broad strokes, no specific impl details from what I saw.
Yup, didn't want to get into the weeds with the specifics, but we use the same procedure as AWS, where we use the shared secret to recreate the signature provided and then match the two (as well as verifying the method performed is allowed in the policy, and the expiry time is correct). Happy to go into more details if you'd like, also available at https://developers.filepicker.io/docs/security/
In reference to the js library as client-side, the key thing we were looking to solve was how to implement a token-based scheme where even if someone had access to the running javascript via xss or just malicious console behavior, the amount of damage they could do would be limited. Balancing that with the simplicity requirements to not use handshakes and allow for embedding urls within <img> tags resulted in the scheme we implemented
Comments
For anyone that kept seeing "HMAC" and thought "What in the hell..." I wrote an article (stream of thought in story format) describing how you might try and secure an API call, how AWS does it and eventually how 2-legged OAuth can be utilized to do it:
http://www.thebuzzmedia.com/designing-a-secure-rest-api-with...
NOTE: This is written from the perspective of "My god, what does this all mean?"
NOTE #2: You can do away with almost ALL of this complexity if you just force everyone onto SSL connections, but then you have to be ok with the increased latency introduced connection-(re)negotiation; just depends on what your API needs to do.
NOTE #3: I think the title of this article is misleading... there is no security on an untrusted client using HMAC -- if your client knows your secret AND they are untrusted, then you have problems.
I wasn't clear from the article how the JS library running client side is adding the secret to the digest before sending the request to the server to verify and process.
For those AWS folks out there, that is what your AWS secret is used for -- your request, e.g.: /ec2/launch?cust=bdillon&size=xl&quant=2&sig=akjDjlasdmnDASkljasd
to sign the entire request, so when AWS receives the request, the first thing it does is attempt to re-create the exact same signature using the secret it has on file for "bdillon" (or whatever customer-identifying info was sent)
This requires both the caller and server to know the secret and I am not clear on how filepicker is solving this from this article... very broad strokes, no specific impl details from what I saw.
Yup, didn't want to get into the weeds with the specifics, but we use the same procedure as AWS, where we use the shared secret to recreate the signature provided and then match the two (as well as verifying the method performed is allowed in the policy, and the expiry time is correct). Happy to go into more details if you'd like, also available at https://developers.filepicker.io/docs/security/
In reference to the js library as client-side, the key thing we were looking to solve was how to implement a token-based scheme where even if someone had access to the running javascript via xss or just malicious console behavior, the amount of damage they could do would be limited. Balancing that with the simplicity requirements to not use handshakes and allow for embedding urls within <img> tags resulted in the scheme we implemented