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

Chris Drake christopher at pobox.com
Thu Sep 25 17:54:25 UTC 2014


Hi John,

No, FIDO turned out to be just-another TOTP implementation (using legacy existing solutions too even).  Nothing in it prevents phishing still, so if they're claiming "end to end" anyplace, it's not the meaning of "end" that you or I would necessarily agree with.  In real life, the "end" that you occupy, is you - not the thing you're typing on, and certainly not the wire coming out the back of it.  If it looks like PayPal, and smells like PayPal, and your funky USB gadget sends your OTP code to it when you push it's button, but when the thing you gave that code to is *not* PayPal, then it's not saving you from phishing.  Or more bluntly, if you can't see the difference between the real paypal, and the fake one, and if that difference isn't part of the mutual authentication solution such that it blocks even inattentive users from being tricked, then you're putting 91% of your eggs in the wrong basket.

Kind Regards,
Chris Drake


Thursday, September 25, 2014, 5:29:37 PM, you wrote:


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:

Re: Review of Proposed Implementer’s Draft of OpenID 2.0 to OpenID Connect Migration Specification 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/44a93407/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CryptoPhoto blocks phishing.png
Type: image/png
Size: 4013 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20140925/44a93407/attachment.png>


More information about the specs mailing list