[OpenID] Phishing resistant policy of PAPE

[Breno de Medeiros]

On Tue, Oct 28, 2008 at 5:41 PM, Eric Norman <ejnorman at doit.wisc.edu> wrote:
>
> On Oct 28, 2008, at 7:21 PM, Breno de Medeiros wrote:
>
>> On Tue, Oct 28, 2008 at 5:12 PM, Eric Norman <ejnorman at doit.wisc.edu>
>> wrote:
>>>
>>> On Oct 28, 2008, at 6:41 PM, Breno de Medeiros wrote:
>>>
>>>> The phishing attack that you presented above is not a phishing attack
>>>> that can be prevented.
>>>
>>> Information cards seem to provide effective resistance.
>>
>> Against sites that ask users for their credit cards?
>
> Yes.
>
>>> Some argue that EV certificates provide such resistance.
>>
>> Against sites that ask users for their credit cards?
>
> Yes.
>
>>> Some even argue that regular old server certificates can
>>> provide such resistance.
>>
>> Against sites that ask users for their credit cards?
>
> Yes.
>
>>>
>>
>> I don't see how any of these technologies prevent against the attack
>> you described.
>
> Because they send a signal to the user that the other end is
> who the user thinks it is.  And a different signal if it isn't.
> In the latter cases, the signal doesn't seem be be blatant
> enough, but it's there.

Ok, so the scenario is:

1. Site example.com is a respectable RP that accepts only PAPE-enabled
OPs, such as unphishable-OP.com
2. Site evil.com is an impostor to site example.com, and wants to get
the user's credit card by impersonating example.com.
3. Site evil.com implements a fake replica of example.com (say
examp1e.com) and uses PAPE to authenticate users via the legitimate
OP.
4. User logs into site examp1e.com using the real unphishable-OP.com
(since OP is using un-phishable authentication) and now is fairly
confident that it is talking instead to example.com and enters the
credit card.

The problem with that scenario is that we are already assuming that
the user is ignoring all types of signals at examp1e.com related to,
e.g., mismatched certificates (which certainly would be present in
example.com's credit card entry page). So neither regular certificates
nor EV certificates that example.com might be employing is actually
helping anything if you assume this attack can work.
The information cards example is more convincing. At least until the
phisher sends an e-mail to the user's phone, including a link to
example.com's "compatibility" site that does not use information cards
for the convenience of not-so-smart mobile browser.

>
> Eric Norman
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)