On Sat, Jan 5, 2013 at 9:48 AM, Anders Rundgren <[email protected]> wrote: > On 2013-01-05 13:51, Jeffrey Walton wrote: >> On Sat, Jan 5, 2013 at 6:54 AM, Anders Rundgren >> <[email protected]> wrote: >>> If two-factor authentication was actually usable (i.e. <keygen> & friends >>> were replaced by something mere mortals could understand), these >>> kinds of attacks would be much less powerful. >> Devil's advocate: what does two factor have to do with setting up a >> secure channel based on a public ca hierarchy? > > My bad, I really meant PKI (which though in my mind should be > complemented by a PIN). The problem here is conferring trust. We confer trust when we ask a CA, "Is this site good" (lot's of hand waiving). We also confer trust when we ask DNS for an IP address. We are making security decisions based on someone else's hearsay.
Giving the user a certificate does not help with that. Taking advantage of the pre-existing relationship (apropos a shared secret) or using 'a priori' knowledge (the server's expected public key) does help with that. One way to achieve the goal is to use a Password Authenticated Key Exchange (PAKE), such as Thomas Wu's Secure Remote Password (SRP). Another is to use certificate pinning. Certificate pinning is similar to SSH's StrictHostKeyChecking. If we know whom we should be speaking with, it does not matter what the CA or DNS answers. > Unlike passwords, PKI-based client-authentication doesn't give > the fake site anything they could use for accessing your account > on the real site. "Phish-safe". Agreed. Never apply your secret to unvalidated systems - it does not matter if its a GnuPG ElGamal key or a foreign website. Jeff >>> On 2013-01-05 05:11, Jeffrey Walton wrote: >>>> Hi All, >>>> >>>> >From Dr. Geer on the Cryptography mailing list >>>> (http://lists.randombit.net/mailman/listinfo/cryptography). >>>> >>>> Its another reason to pin your certificates. Stop accepting the >>>> "broken" as the "norm". >>>> >>>> Not everyone is a bank who can be irresponsible and pass losses caused >>>> by mistakes onto share holders in pursuit of profits (re: risk >>>> acceptance). In some cases, people's lives depend upon it. >>>> >>>> +1 to Google and AOSP for recognizing the problem, and taking action >>>> early. I owe the security team a beer. >>>> >>>> Jeff >>>> >>>> ---------- Forwarded message ---------- >>>> From: <[email protected]> >>>> Date: Fri, Jan 4, 2013 at 6:40 PM >>>> Subject: [cryptography] another cert failure >>>> To: [email protected] >>>> >>>> you may have already seen this, but >>>> >>>> http://www.bbc.co.uk/news/technology-20908546 >>>> >>>> Cyber thieves pose as Google+ social network >>>> >>>> The lapse let cyber thieves trick people into thinking they were >>>> on Google+ Continue reading the main story Related Stories >>>> Cyber-warriors join treasure hunt Insecure websites set to be named >>>> Warning over web security attack Web browser makers have rushed to >>>> fix a security lapse that cyber thieves abused to impersonate Google+ >>>> >>>> The loophole exploited ID credentials that browsers use to ensure >>>> a website is who it claims to be. >>>> >>>> By using the fake credentials, criminals created a website that >>>> purported to be part of the Google+ social media network. >>>> >>>> The fake ID credentials have been traced back to Turkish security >>>> firm TurkTrust which mistakenly issued them. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
