Topic #2: Anti-Phishing Solution
- Introduction
- Current Solution in the 08 Draft
- Drawbacks to this Solution
- Alternative Solutions
- Discussion
1. Introduction
The subject of how to prevent phishing attacks against ISSO has been widely discussed by XDI.ORG and Identity Commons developers. This topic is to come to closure on this issue so implementations can be completed and user testing begun.2. Current Solution in the 08 Draft
The the 08 version of the IservicesSpecs incorporates the following anti-phishing solution:
-
The i-broker looks for an ISSO authorization cookie at the time of the authentication challenge.
-
If the ISSO authorization cookie is present (meaning this browser has previously been authenticated for the relevant i-name or i-number), then the user is presented with their personalized authentication challenge (PAC) page (showing preferably a picture selected or uploaded by the user, or alternately a personalization phrase of their choosing).
-
If the ISSO authorization cookie is not present (meaning this browser has not previously been authenticated for the relevant i-name or i-number), the user is NOT presented with their PAC page but requested to manually navigate to the i-brokers home page in order to prevent phishing attempts. Once the user has manually navigated to the i-brokers home page, the user can login there and (if desired) set the authorization cookie for this new browser.
3. Drawbacks to this Solution
-
The requirement to manually navigate to the i-broker's home page is burdensome to users.
-
Users must understand not only the general rule (NEVER enter their i-broker password unless they see their PAC page) but also a critial exception (UNLESS they user manually navigates to the i-broker's home page.)
-
When manual navigation to the i-broker is required, the i-broker must maintain state on an ISSO request from a relying party for at least 5 minutes.
4. Alternative Solutions
4.1. #1: Allow Non-Personalized Login
In this alternative, a user is not forced to manually navigate to their i-brokers home page, but only educated that IF THEY DO NOT SEE THEIR PAC PAGE, the user should be extra careful about entering their i-broker password, and if there is any doubt, the user should manually navigate to their i-brokers home page.Of course, a phishing site impersonating an i-broker will either: a) not include the latter instructions, or b) include them anyway and rely on a spoofed domain name or other mechanism to trick the user into entering his/her i-broker password.
4.2. #2: Personalization Challenge
Another alternative is a separate "personalization challenge" if there is no ISSO authorization cookie. In other words, if the ISSO authorization cookie is not present, the user is presented with a page where the user is NOT asked for their i-broker password, but only for a word or phrase used to provide enough authentication for the i-broker to present the user's PAC page on the following page. If the user successfully enters their personalization phrase, the broker presents the user's fully personalized PAC page for entry of the user's password and ISSO proceeds as currently specified.The primary problem with this solution is that it only makes it one step harder for an attacker. In other words, if a phishing site successfully phishs a personalization phrase, it can gain access to the user's PAC page, then "scrape" that and show it to the user to fully impersonate the i-broker.