Ben Laurie

OK, I regard this as an opportunity to learn. So far I have invested about 3 hours in trying to understand how I can use OpenID to do what I do now, and I feel none the wiser, and resent the loss of time. You appear to be that rarest of things - a knowledgable enthusiast who will try to communicate clearly.

So, here I am, approaching a new site that requires authentication. Under my current workflow I select a userid, which may, but need not, replicate an existing userid. I select a password which is unique, and an email address which is unique. I use these credentials to signup, then reply to the confirmation email.

Now I have an account on the new service using a userid with a unique password. If that password is compromised, none of my other accounts are compromised. Further, if the email address I use gets leaked, I know who leaked it. This is how I have confirmed that eMusic are email address leaking bastards.

This last capability is important to me, just as is the ability to use unique passwords wherever I go to avoid one leak compromising multiple accounts.

Can you now point me at a document that will show how to obtain the above facilities? I'd appreciate it.

Thanks.

EDIT:

In positioning myself to understand what you write or point me at, I have further found this:

http://www.links.org/?p=187

I'd appreciate your comments on that as well. Thanks.

Amazing example. Blindly doing anything because of Valgrind is bad, but I think a better rule might be "Don't comment out lines you don't understand in a standard cryptography package and then distribute it to users without warning". I don't think a mere "mention of the need for caution" could have saved anyone here. Handcuffs and a straightjacket on the Debian developer might have been required in this case.

This link covers it well:

What can we learn from this? Firstly, vendors should not be
fixing problems (or, really, anything) in open source
packages by patching them locally – they should contribute
their patches upstream to the package maintainers. Had
Debian done this in this case, we (the OpenSSL Team) would
have fallen about laughing, and once we had got our breath
back, told them what a terrible idea this was. But no, it
seems that every vendor wants to “add value” by getting in
between the user of the software and its author.

Secondly, if you are going to fix bugs, then you should
install this maxim of mine firmly in your head: never fix a
bug you don’t understand. I’m not sure I’ve ever put that
in writing before, but anyone who’s worked with me will
have heard me say it multiple times.

http://www.links.org/?p=327

> I'm aware of the Chrome sync passphrase. If I used Chrome on Android (I don't—I use Firefox), would Chrome back my passphrase up to Google's systems? I dunno.

At least the docs claim that it's only saved on your device. You can believe it or not. There may be a way to verify that it's not being backed up with your normal Android data, but I'm not sure.

> Is the crypto behind Chrome's sync anywhere near as good as that behind Firefox's? Not last time I looked.

It's never been not good. Maybe you're thinking of back when they didn't have the option to encrypt all your sync data locally, just your passwords? It uses Nigori[1] and the source is all available[2].

This is a little old, but it compares browser syncing security: http://gregoryszorc.com/blog/2012/04/08/comparing-the-security-and-privacy-of-browser-syncing/

> I'm also aware that email often travels via SSL—but it's always cleartext to the sending and receiving hosts

Fair enough, but if you're using PGP, those hosts are only the actual sender and recipient (and anyone the recipient shares an email with, of course).

[1] http://www.links.org/files/nigori-overview.pdf

[2] https://src.chromium.org/viewvc/chrome/trunk/src/sync/util/nigori.cc

1) You can address it in Chrome with pinning [1]. Built in pins require that you be a significant site, but you can also set them with HTTP headers [2].

[1] http://www.imperialviolet.org/2011/05/04/pinning.html
[2] http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01

This is a rather poor solution. The longer term one is Certificate Transparency: http://www.links.org/?p=1219

2) is solved with HSTS [3]. You can contact me (@chromium.org) to be built in. There isn't a notability requirement.

[3] http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

3) The BEAST attack was tough to pull off and is fixed with Chrome, FF10 and IE.

http://www.imperialviolet.org/2012/01/15/beastfollowup.html

4) Yep, cookies must be marked secure. HSTS can also fix this my eliminating the insecure requests. Even with secure cookies (but without HSTS), a MITM can also set the cookie. (i.e. to log you in to their account before you hit 'send' and then to log you back into yours before you notice the problem.)

That's a common misconception. Solutions to the Byzantine generals problem have been known for a while. Researchers are still looking for more efficient solutions, but PBFT introduced in 1999 is already, well, practical.

The main problem with anonymous consensus are Sybil attacks. You need a way to limit the size of the consensus pool. Bitcoin does that using proof-of-work (quite elegantly, Bitcoin's PoW does actually a lot more than that, but this is really it's raison d'etre).

I recommend reading Ben Laurie on the topic. http://www.links.org/files/decentralised-currencies.pdf

---

If you look at the current problem with DTCC, you'll notice is has little to do with centralization, and more to do with the fact that there is no technological transparency. If all of these systems ran with well defined API, most of the issues would go away.

What financial are mostly after is a shared ledger with programmatic access. Distributed is just a nice add-on.

OCSP was supposed to block fraudulent certificates (as long as the break-in is noticed and published); because of softfails the protocol fails at this task.

Google's security researchers are proposing an incrementally deployed, admin-friendly way to prevent fraudulent certificates: Certificate transparency. Part of it is a public log of what certificates were issued, so that site ops notice when a certificate is issued which they didn't ask for.

Details: http://www.links.org/?p=1212