> 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. > 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/ -- 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: [email protected] <[email protected]> on behalf of Watson Ladd <[email protected]> Sent: 12 November 2013 16:14 To: Phillip Hallam-Baker Cc: perpass Subject: Re: [perpass] Stopping password sniffing On Tue, Nov 12, 2013 at 8:05 AM, Phillip Hallam-Baker <[email protected]> wrote: > The biggest weakness in Internet protocols is relying on passwords for > authentication. What can we do to make the password mechanisms more secure > and to wean the Internet off passwords? Passwords are fine provided they are not reused, and transmitted over secure channels. > > I don't want to start an NSA rathole here, but I need evidence to support > the above assertion and until the GRU or MOSSAD or PLA or whatever have > their Snowden event, I am limited to using the NSA. > > 1) NSA using Password sniffing in Attack: > http://boingboing.net/2013/11/11/gchq-used-fake-slashdot-linke.html > > 2) The NSA gets rolled by Snowden using password sharing: > http://www.reuters.com/article/2013/11/08/net-us-usa-security-snowden-idUSBRE9A703020131108?irpc=932 > > > I don't think this problem is as insoluble as many imagine. What I think has > been the show stopper is that strong authentication techniques are an all or > nothing proposition that require both the site and the user to adopt before > the scheme is useful. This double ended adoption requirement invariably > leads to deployment deadlock in my experience. Client certificates are already supported and widely deployed. The DOD uses them on smartcards for just about everything. The big problem is a UI issue. > > What I suggest as an alternative is the following: > > 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. > > 2) The password in the cloud scheme uses randomly generated passwords that > are unique for each site and have 128 bits of randomness (min). > > 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. And we still have passwords being used. The direct exchange=autofill. > > I believe that we can make cloud log in a more secure option than current > single factor authentication. Remember that 95% of Internet accounts are not > financially sensitive. An authorization in the cloud service is completely > acceptable to me as a means of storing my Slashdot username and password. So why does it need a 128-bit strong password? The issues you raised involve much stronger issues. > > The remaining 5% have important security concerns but the real issue is > confirming critical transactions rather than access control to view the site > info. A simple cloud log in scheme is more than sufficient for access to > view my account details but I want a strong second factor to verify > transfers out of my account place stock trades, etc. Somehow my mother's bank sent her a smart card and reader to validate transactions. Other banks use lists of one-time passwords, etc. This can be done today if the customers care. > > > I plan to return to this after I get email security on a solid track with > some code. > > -- > Website: http://hallambaker.com/ > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
