[security] Making phishing hard without changing UA side protocol

[thayes0993 at aol.com]

 I believe that option #2 is the correct one to recommend at this time. While this is clearly outside of the openID protocol itself, remaining silent on the potential phishing attacks is not going to help promote openID in the long term.
  
 Unless other mechanism are in place to prevent phishing (see below) the OP must:
 
 1) suggest that users login to the Open ID provider prior to accessing any Open ID-enable site.
 2) refuse to display a login page in response to an authentication request. Instead, the OP must direct the user to navigate to the OP on their own, by using a bookmark or typing in the URL directly. NOTE: the OP may record the authentication request for this user, and continue the processing the request after credentials have been presented.
 
 These constitute the most basic defense against phishing.
 
 The OP may provide other measures to prevent phishing, such as:
 1) using some form of credential that guards against phishing (SRP, site-specific password digests, Cardspace, public keys, full PKI...)
 2) personalized content on the login page, together with educating the user to look for the content (Yahoo, Bank of America...)
 3) detecting the presense of appropriate client extensions that guard against spoofing. (petname toolbars etc)
 
 Can we agree that this level of recommendation should be included in the protocol spec?
 
 Terry 
 
 -----Original Message-----
 From: hgranqvist at verisign.com
 To: security at openid.net
 Sent: Mon, 22 Jan 2007 10:59 AM
 Subject: [security] Making phishing hard without changing UA side protocol
 
  Just some quick thinking how phishing for passwords can
be diminished without severely changing the protocol or
enforcing UA plugins, etc.

1. The OP requires:
    -- a RP must associate before the OP accepts it
       (as a return_to/trustroot).
    -- before OP allows such association, the RP must
       provide an acceptable XRDS file(*).

2. The OP refuses to do a login at the same time
    as an authentication. The user must be logged in
    beforehand.

Of course, 2. is a user education, but maybe not that
hard to teach?

Does OpenID delegation change the assumptions?

-Hans

(*) The OP decides what is acceptable. The XRDS can
contain 3rd party-verifiable cryptographic tokens, for
example.
_______________________________________________
security mailing list
security at openid.net
http://openid.net/mailman/listinfo/security
   
________________________________________________________________________
Check out the new AOL.  Most comprehensive set of free safety and security tools, free access to millions of high-quality videos from across the web, free AOL Mail and more.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openid.net/pipermail/security/attachments/20070122/a7c0fa7d/attachment-0001.htm