Hi Adam, A few thoughts....
On Wed, Jan 16, 2013 at 6:02 PM, Adam Back <a...@cypherspace.org> wrote: > There was a subthread in this huge PKI-is-failing and doesnt solve phishing > thread looking at what might solve phishing (modulo engineering and > deployment issues). > > To summarize Ian & Ben mentioned and I add a few: > > - client side certificates Good, but I don't know how I am going to teach my grandmother how to use them (seriously). She's in her 90s, and is barely hanging on to AOL (the internet on training wheels). Plus, the password did not go away (it was just shifted) since it protects the PKCS#12 certificate. > - password managers Lots of bad 'local' implementations, and a 'remote' installation confers trust (and may also suffer a bad implementation, too). > - browser auth Anything browser related is untrustworthy - from application to platform. Trust zones have been re-written, and its equivalent to: using YOUR browser on YOUR phone is like using a public kiosk at a mall. No malicious plug-ins or evil Javascript are required. Browsers and the vendors have brought this on themselves in their desire to fondle the user's (and the complimentary endpoint's) data. > - TPM to make credentials harder to steal TPM is not widely deployed, and is perceived as something from the Evil Empire in Redmond. Its only gotten worse since Windows {8|RT|Phone} implemented UEFI's Secure Boot. Linux folks are already complaining. I am a proponent since there is no user interaction required, and it takes away, for example, DFU Mode/Recovery Mode tricks on Apple's mobile gear. A good treatment of the subject for Windows (no need to ask Miller, Zavi, Zdziarki, et al, to discover security related matter): http://channel9.msdn.com/Events/TechEd/Europe/2012/WPH304. > - SRP, EKE I like SRP since it does not confer trust to third parties. Standard password cracking still applies, though. SRP uses DH-based exchanges, while EKE exchanges are cipher-based. So SRP is a harder problem, I believe. In addition, DH-based problems do not require export licenses (they are authentication schemes) where cipher based schemes usually do (they are considered encryption schemes). > - channel bound auth A properly design channel will be resilient to replay. Perhaps there are other desirable attributes not offered in other schemes that I am missing. > - two factor OTP I like a second factor to improve assurances. Unfortunately, not everyone has access to the second factor's channel (telephone, cell phone, RSA token). And I'm not sure how to teach my grandmother how to use it. > - single sign on vendors Confers trust. Asking {Google|Yahoo|Facebook} for the OAuth token is no different than asking a CA if the certificate is good. > So clearly the end game is not passwords... But it looks like they are still an integral part of the overall solution. Jeff _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography