On 2013-01-05 16:02, Jeffrey Walton wrote: > 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.
Although I'm not proposing this, a client certificate could also serve the same purpose without requiring a shared secret. I.e. the certificate could contain a certificate extension holding a trust list. If you have a mobile device that's an easy thing to do because it doesn't require any new auth protocols. We just have to nuke <keygen> :-) > > 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.
