Security on an untrusted client - locking down a javascript library

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:<p><a href="http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/" rel="nofollow">http://www.thebuzzmedia.com/designing-a-secure-rest-api-with...</a><p>NOTE: This is written from the perspective of "My god, what does this all mean?"<p>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.<p>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.<p>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.<p>For those AWS folks out there, that is what your AWS secret is used for -- your request, e.g.: /ec2/launch?cust=bdillon&#38;size=xl&#38;quant=2&#38;sig=akjDjlasdmnDASkljasd<p>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)<p>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.

Critical feedback: This article doesn't seem to be grammar-checked and there's at least one paragraph that is incomplete. The entire thing is difficult to read or understand even for someone with crypto knowledge. I recommend getting future articles peer-reviewed by a layman.

Cool article,<p>I think as a first step the approach makes sense. I'd propose security is broader than secrets--I think one frame is Authentication, Authorization and Audit (sometimes called the "Gold Standard", because of the repeated "AU" prefixes. Haha, CS meets chemistry humor.).<p>Anyway... In my mind, Authentication is about secrets, but that can fail. So you use Authorization, so when bad people get access you limit what's compromised. When those two fail, you at least have Audit to either catch the bad actor when they start making trouble, or at worst you can figure out how to stop breaches in future.<p>And these can mix and match. My two cents.<p>Thoughts?

TLDR; we use hmac signed requests with expiration a la AWS

"<i>being able to encrypt a message is proof that they are who they say they are</i>"<p>Not true. All that that proves is that whoever is on the other end knows the secret.<p>In that sense the title ("<i>Security on an untrusted client</i>") is misleading. The only way anyone's going to secure an untrusted client to a point where the system gains my trust is by using:<p>- A one-time password [1] to mitgate MITM, key loggers and screen grabbers.<p>- Identity federation (<i>not</i> OpenId or OAuth) that means I can use credentials other than the credentials I use from a trusted client.<p>- An application firewall [2] that redacts HTML on the fly so that the disclosure impact of a single GET request is reduced.<p>- Ideally (although this is taking things to a whole new level of paranoia) a data diode [3] that protects my server.<p><i>[Edit]</i> The use case will obviously drive out the requirements, and the shopping list above is for a basic web application that only goes as far as form data. If you're looking to work with files you'd have to write up some code that ensures files don't contain nasties. While AV will go some way to doing that, the only way to <i>really</i> get around that is through conversion. I.e. .DOCX is converted to .PDF, .PNG to .JPG, and so forth. Yes, that limits the file types you can deal with, but if you're this far down your requirements aren't exactly main stream.<p>[1] RSA SecureId (<a href="http://en.wikipedia.org/wiki/RSA_SecurID)or" rel="nofollow">http://en.wikipedia.org/wiki/RSA_SecurID)or</a> Chip &#38; PIN challenge/response (<a href="https://en.wikipedia.org/wiki/Chip_Authentication_Program" rel="nofollow">https://en.wikipedia.org/wiki/Chip_Authentication_Program</a>)<p>[2] Eg. F5 Big-Ip app security manager (<a href="http://www.f5.com/products/big-ip/big-ip-application-security-manager/overview/" rel="nofollow">http://www.f5.com/products/big-ip/big-ip-application-securit...</a>) or Microsoft's Unified Access Gateway (<a href="http://www.microsoft.com/en-us/server-cloud/forefront/unified-access-gateway.aspx" rel="nofollow">http://www.microsoft.com/en-us/server-cloud/forefront/unifie...</a>).<p>[3] Tenix is a high-end solution used by governments. The old Whale Commuications Intelligent Application Gateway used to be a cheap but very effective alternative (<a href="http://en.wikipedia.org/wiki/Unidirectional_network" rel="nofollow">http://en.wikipedia.org/wiki/Unidirectional_network</a>).

"being able to encrypt a message is proof that they are who they say they are"<p>This is not exactly right. Encryption ensures people cannot eavesdrop on a message but it does not ensure you can verify the sender. You need authentication instead, which is what HMAC does in this case.

"Security breaks when humans are involved"<p>Pretty much sums up life. It's gotten to the point that zero-day exploits scare me less then users writing passwords down on sticky notes, clicking on random links, or letting random people in the building.