I'm talking about storing TLS client certificates encrypted in the cloud and synchronising them across browsers, decrypting them client side with a symmetric key generated from a password.
This removes a lot of the password specific problems like simply replaying a password that the NSA saw you type through a CCTV camera. RFC2246 contains details about how clients can authenticate to servers using TLS. The fact that TLS is being used would also mean the connection is encrypted, avoid sniffing of the wires being a problem (unless the server's priv key is compromised or unless there's a downgrade attack and a NULL cipher is used or a poor cipher is used). It's encrypted to prevent the cloud provider from being able to hand over the certificate. It doesn't necessarily have to encrypted and synchronised in the cloud, an alternative is smartcards for storage or USB dongles. These devices are already readily available[1]. Iain. [1]: http://g10code.com/p-card.html -- Iain R. Learmonth MBCS Electronics Research Group School of Engineering University of Aberdeen Kings College Aberdeen AB24 3UE Tel: +44 1224 27 2799 The University of Aberdeen is a charity registered in Scotland No.SCO13683 ________________________________ From: Robin Wilton <[email protected]> Sent: 12 November 2013 16:50 To: Learmonth, Iain Ross Cc: Watson Ladd; Phillip Hallam-Baker; perpass Subject: Re: [perpass] Stopping password sniffing Hi Iain, On 12 Nov 2013, at 16:28, Learmonth, Iain Ross wrote: 1) The user decides to unilaterally use a password in the cloud scheme that allows them to store their passwords on one machine and access them from any of their browsers. I already do this with LastPass[1]. If we want to move forward with authentication for things like websites though, I'd rather see the cloud storing encrypted client certificates that are synchronized and then decrypted client side by a password. This sounds interesting and rational, but it contains a lot of implied detail. Can you unpack it a little, e.g. explaining what's in the certificate, why it needs to be stored in that form, why it's encrypted, which steps of the protocol are assumed to depend on session-level encryption, and so on? Thx, Robin 3) The browser implementing the password in the cloud scheme alerts the site being contacted to the fact that it can support a direct user authentication exchange that would make the user experience seamless and support single sign on. LastPass can do an "auto-login", but this would be completely seamless with TLS client certs. If the site has to be changed anyway, why not do it properly? This also leaves the option of having my certs on a smartcard, USB dongle, floppy disk, etc. instead of just in the "cloud". Of course, if you wanted to build a system that syncs client certs, you could also add synchronizing of passwords into it, but I think that would only really discourage the adoption of the client certs. Iain. [1]: https://lastpass.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
