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
