Ask HN: Is sending passwords a good use of JS crypto?
2 comments
First, have you read http://www.matasano.com/articles/javascript-cryptography/?
I hadn't yet seen that particular article but I'm very familiar with those arguments. Thanks for the link!
I agree with them that building a crypto library in JS that can be trusted regardless of the security properties of the web application is impossible (content-controlled code, runtime malleability).
However, I don't think those points mean that building an application that as a whole has good security properties and uses JS crypto is impossible. If the entire application code is delivered on first load and code is never dynamically loaded, one should be able to audit and trust that complete application. That'd mean no ads, no google analytics, no CDNs, etc.
The next bit is reliable delivery. SSL is definitely needed. Because static code is all delivered on first load, an interested third party could download it at any time and see that it matches the audited code. The host would be caught if it attempted any attack that wasn't narrowly targeted.
And that's why it's better than just SSL. If the host receives the plaintext, there's zero chance of catching them.
Their points about graceful degradation and CSPRNGs are irrelevant; I'm only interested in targeting modern browsers with window.crypto.getRandomValues.
I agree with them that building a crypto library in JS that can be trusted regardless of the security properties of the web application is impossible (content-controlled code, runtime malleability).
However, I don't think those points mean that building an application that as a whole has good security properties and uses JS crypto is impossible. If the entire application code is delivered on first load and code is never dynamically loaded, one should be able to audit and trust that complete application. That'd mean no ads, no google analytics, no CDNs, etc.
The next bit is reliable delivery. SSL is definitely needed. Because static code is all delivered on first load, an interested third party could download it at any time and see that it matches the audited code. The host would be caught if it attempted any attack that wasn't narrowly targeted.
And that's why it's better than just SSL. If the host receives the plaintext, there's zero chance of catching them.
Their points about graceful degradation and CSPRNGs are irrelevant; I'm only interested in targeting modern browsers with window.crypto.getRandomValues.
You can't just audit the code. You have to audit the whole runtime, every time the app touches the web server. It's not a tractable problem.
As you think about this, consider the impact that plugins, that your JS doesn't know about, and how they play with the entire runtime of the browser.
Also, I find this blog post somewhat less than amusing in general about how browsers work: http://lcamtuf.coredump.cx/postxss/
Also, I find this blog post somewhat less than amusing in general about how browsers work: http://lcamtuf.coredump.cx/postxss/
It isn't clear that you are properly taking into account the fact that a browser (also known as a user-friendly Remote Code Execution Engine) is an especially hostile environment.
What's the point of this? The server that feeds the Javascript that generates the PGP keys and any server that feeds the Javascript code that performs PGP operations can read arbitrary messages. Why bother with the rubber chicken crypto? Just have users send you plaintext messages over SSL and be honest about it.
The server can only read arbitrary messages if it changes the runtime that it serves. If it were to serve the wrong runtime to more than a narrowly targeted set of users, it could be detected (by, say, a third party running an automated script to check for changes in the served files).
This also means that targets of interest would have to be identified at time of their use of the service (so as to avoid detection as above) by something other than the content they're sending, whereas a malicious service receiving the plaintext could search through all received plaintext for interesting content without detection.
It would make an attacker expend effort and risk per-target. In a world of mass data collection, that seems valuable for those who aren't targets of particular interest but want to avoid the dragnet.
This also means that targets of interest would have to be identified at time of their use of the service (so as to avoid detection as above) by something other than the content they're sending, whereas a malicious service receiving the plaintext could search through all received plaintext for interesting content without detection.
It would make an attacker expend effort and risk per-target. In a world of mass data collection, that seems valuable for those who aren't targets of particular interest but want to avoid the dragnet.
The DOJ didn't want everyone's mail at Lavabit. It wanted Snowden's mail. The DOJ will feed malicious JS to its targets, and innocuous JS to everyone else.
Yep. They would. Snowden should be using PGP on an air-gapped machine inside a faraday cage, right? This isn't for him. This is for the rest of us that are at most mildly interesting but don't want to give in to the surveillance state, or just want to send a password without blindly and completely trusting at least one third party. Isn't such a mid-security but easy to use solution valuable? The more PGP-armored messages there are (even if they could be broken with effort), the less suspicious any such use of crypto can be considered.
There is virtually no correlation between the people who need to have their secrets protected from hostile governments and the people who are savvy enough not to use applications that make security promises they can't keep.
The security promise is simply "this is better than plaintext email, which is what you'd use otherwise."
I'd rather have as much of my communication as possible protected from mass collection by my own government regardless of it's sensitivity.
Edit: Misunderstood your phrasing a little. Yes, ideally we would provide non-savvy users with trivially easy to use encryption strong enough to defeat hostile governments. I haven't seen it yet. I make no pretense of overpromising - I'd certainly expect a service such as I'm describing to prominently note that it shouldn't be used for material above a certain sensitivity and link to info on better options.
I'd rather have as much of my communication as possible protected from mass collection by my own government regardless of it's sensitivity.
Edit: Misunderstood your phrasing a little. Yes, ideally we would provide non-savvy users with trivially easy to use encryption strong enough to defeat hostile governments. I haven't seen it yet. I make no pretense of overpromising - I'd certainly expect a service such as I'm describing to prominently note that it shouldn't be used for material above a certain sensitivity and link to info on better options.
A security conscious web developer needs to share credentials with a client. The client isn't adept enough to install a crypto tool. They also need something asynchronous like email - a phone call every time is too intrusive. Existing options include: 1. Email. 2. A third party service with SSL w/ PFS + server side encryption as an intermediary. A malicious service can keep a copy without detection.
With in-browser crypto: - Dev asks client to go to http://sendpasswords.com/. - Client hits the link. Browser generates a PGP keypair, stores the private key in localStorage and sends the public key to the server. The client is shown a link to send back to the developer. - Developer visits link and enters a message which is encrypted with the client's public key in browser. - Client returns to site. Encrypted message is downloaded and decrypted with key from localStorage.
This should be at least as good as either existing option. A few additional security assumptions: - Users know to only access the site via an HTTPS URL or HSTS settings are preloaded in their browsers. - The HTML + JS is simple, unobsfuscated, static and served in one request; subsequent data from AJAX calls is never executed or loaded as HTML. - Only browsers providing a CSRNG are supported. - The HTML + JS is open source and audited by a third party.
The host would have a hard time capturing cleartext without detection. They could target specific users, but third parties could periodically load the app and verify the checksums to detect any code change that wasn't narrowly targeted.
So long as the audited code couldn't encrypt the message for more than one public key, any interception would be detected when the recipient didn't get the message.
Thoughts?