Most of the work on bidirectional authentication for the primary authenticator is happening in FIDO the U2F protocol secures the connection end to end if I understand correctly. Or at least that was Googles goal when they started U2F.
In OAuth we are working on proof of possession, but that is different from what you are asking about. John B. Sent from my iPhone > On Sep 25, 2014, at 2:54 AM, Chris Drake <christop...@pobox.com> wrote: > > Hi Nat, > > Yeah, two-step (TOTP) blocks keyloggers, not phishing (TOTP was invented in > 1984, before we had networks and real-time attacks). breakins worldwide have > doubled in the last 12months, and risen 800% in the banking industry, almost > exclusively on the back of phishing... risk-based and multifactor are both > widespread, and absolutely not working (and don't get me started on the > stupidity of "risk based" - the false positives are making the internet > unusable for travelers and other legit people, and having no effect > whatsoever on crime). > > The protocol is the cause of the problem. It's one-way-only, which is why > phishing is working so well. It's not enough to authenticate a user to a > site, the opposite needs to take place as well, at the same time, as part of > the protocol. > > Kind Regards, > Chris Drake > > > Thursday, September 25, 2014, 6:12:01 AM, you wrote: > > > Most large providers, as I understand, are using risk based authentication > and also offers two-step or two-factor authentication. > So, simply stealing password would not work: they are phishing resistant. > It looks more like a deployment issue than a protocol issue to me. > Correct me if I am wrong. > > Man-in-the-browser attack is something else. It needs continuous or second > channel authentication. This looks more interesting from a protocol point of > view. > > Nat > > 2014-09-25 2:14 GMT+09:00 Chris Drake <christop...@pobox.com>: > Hi Nat, > > I remember back when the original OpenID was forming, and a bunch of my > suggestions got shoved "out of scope"... which are now being brought back in > to scope via OpenID Connect. It's cold comfort, but at least I get to brag > "I told you so" after the fact:-) > > Scratch the surface of any megahack, and 9 times out of 10 it was caused by > phishing. Personally, I don't see the point wasting effort on OpenID Connect > when it's merely going to exacerbate what is already a crippling problem. > > There's a bunch of smart and experienced people on this list - they should > put their heads together and use the power and knowledge present to fix what > is reported at being behind 91% of the worlds security problems, most > especially when OpenID users are significantly more vulnerable to these > attacks, and at-risk once attacked. "Get it right" is better than "get it > now" IMHO. > > Kind Regards, > Chris Drake > > > > Wednesday, September 24, 2014, 9:57:03 PM, you wrote: > > > The authentication mechanism itself is out of scope. > You can, as an OP, select whatever the authentication mechanism you may want > to use. > OpenID Connect is concerned about transferring the information around the > authentication event to another party. > It is a federation protocol. > > Nat > > 2014-09-25 1:17 GMT+09:00 Chris Drake <christop...@pobox.com>: > Hi, > > Can anyone tell me if any kind of mutual-authentication or other kind of > phishing-protection is present anywhere in the specs? > > Kind Regards, > Chris Drake > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > _______________________________________________ > specs mailing list > sp...@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ specs mailing list sp...@lists.openid.net http://lists.openid.net/mailman/listinfo/openid-specs
