In terms of minimizing password pain/insecurity, you should check out the work of the Fido Alliance, which seems very promising to me. They are trying to cook up a protocol to describe the use of various 2-factor hardware such as smart cards, USB keys, number dongles, biometrics, and so on, so that you can use that stuff without getting tied to a particular vendor/implementation. Yubikey has some very slick demos.
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? > > 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. > > 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. > > > Note that this almost describes where we are right now. Pretty much every > browser already offers password in the cloud service. They are forced to by > market forces. But they don't support an interoperable, standards based > password in the cloud service which is the requirement for us to get to > step 3. > > Interoperability is also a requirement to get to step 2. > > I am not going to lock myself into one browser no matter how much the > management of Google or Firefox or Apple or Microsoft want that. It is not > going to happen and that is why I can't let the browser generate the > password for me. > > > 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. > > 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. > > > 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 > >
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
