Ben Laurie blathering

Nigori: Storing Secrets in the Cloud

Lately, I’ve been thinking about phishing. Again. If we want users to take our sensible advice and use different passwords everywhere, then they’ve got to be able to remember those passwords and move them from machine to machine. In order to do that with any ease, we’ve got to store them in the cloud. But the question is, how to do that securely?

So, that’s what I’ve been working on for a while, and the result is Nigori, a protocol and open source implementation for storing secrets in the cloud. It doesn’t require you to trust anyone (other than your completely insecure client, of course … I’m working on that, too). The storage server(s) are incapable of getting hold of the keying material, and if you want you can use splits to ensure that individual servers can’t even attack the encrypted secrets.

Of course, Nigori isn’t just for passwords, you could also use it to store private keys and the like. For example, Salmon can use it to store signing keys.

The source is in a bit of a state right now, following some hack’n’slay related to appspot’s crypto … oddities, but I’ll post about that soon. For now, in case you missed it above, here’s an overview document.


  1. Sounds great, but the description presently seems a bit — umm — filtered.

    Comment by Mordaxus — 18 May 2010 @ 23:51

  2. How does this compare to PasswordSafe/PasswordGorilla + a file-sharing service like getdropbox?

    Comment by Anonymous — 19 May 2010 @ 11:56

  3. Interesting.

    So the user remembers only a master password. Neither the master password nor its equivalent is stored on any particular server, yet the user can use this to login to any registered service.

    How does this protect against phishing? The user is expected to enter their master password into something in order to use a web site. If that something resembles a web browser (or a web browser can be made to resemble it), then a phishing site can obtain the users master password? Is this an improvement for those of us who actually do use different passwords at every site?

    The auth systems involving chains of redirects require perfect https usage. Any resource retrieved with plain http has the potential to put the entire control flow into the hands of the bad guy. A breakdown in PKI compromises everything, too. Rather than decrypting site-specific passwords, perhaps the SP could issue session-specific client certs.

    Comment by Marsh Ray — 19 May 2010 @ 19:41

  4. I have been planning something similar, but I succumbed to Xanadu disease – planned features have been increasing, while working code decreases. I look forward to seeing something I can actually use.

    Comment by James A. Donald — 20 May 2010 @ 4:24

  5. Its really a bad habit that everyone starts writing “papers” on their new invention and then forget to include the two sentences that state why their solution is supposed to be secure. Or maybe I just missed them. Why would you send your credentials onto a server for the world to launch bruteforce attacks on your passwords?

    I like this approach better:

    However, it has a similar problem in that decryptions with false pw guesses can be detected due to bad values/encoding in the result..

    Comment by lispler — 20 May 2010 @ 18:00

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress