Re: Review of Proposed Implementer’s Draft of OpenID 2.0 to OpenID Connect Migration Specification

[John Bradley]

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 <christopher at 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 <christopher at 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 <christopher at 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
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20140925/8e2f2cd1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2734 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20140925/8e2f2cd1/attachment.p7s>