Ask HN: Is sending passwords a good use of JS crypto?

4 points by mballantyne 12 years ago | 11 comments

I've read previous discussions on the faults of browser crypto but haven't come away satisfied. Can anyone suggest problems with the following?

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?

tptacek 12 years ago |

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.

mballantyne 12 years ago | |

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.

tptacek 12 years ago | | |

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.

wglb 12 years ago |

First, have you read http://www.matasano.com/articles/javascript-cryptography/?

mballantyne 12 years ago | |

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.

tptacek 12 years ago | | |

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.

wglb 12 years ago | | |

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/

wglb 12 years ago | | |

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.