Search this site

Issues with current OpenID provider implementations

Protecting RPs and users from unauthorised token changes

Just an observation when investigating VeriSign Labs' (superb) support for the OpenID "PAPE" specification:


I'm specifying that my site requires VeriSign to authenticate the user with two-factor physical security:

http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical

This works well. If I authenticate successfully with my VeriSign One Time Password (OTP) token then I get the following responses as confirmation that the user was authenticated as requested:

http://schemas.openid.net/pape/policies/2007/06/multi-factor
http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical

Note that if I choose "Click here if you don't have your VIP credential." and use the fact that I have access to my email account to authenticate me then it only comes back with:

http://schemas.openid.net/pape/policies/2007/06/multi-factor

This seems like the correct behaviour to me. The system is saying that even though I requested physical token authentication, it didn't do it this time. My question is based on the following scenario:
  • User has their account protected by a physical VeriSign OTP token.
  • Hacker has user's username, password and access to email. e.g. they had access to the user's PC last week.
  • Hacker logs into user's account using "Click here if you don't have your VIP credential."
  • Hacker removes the user's existing OTP token from the user's account.
  • Hacker adds his own OTP token to the user's account.
While there is certainly a need to handle the lost tokens use case, sending a one time password to the user's registered email address is not secure enough. If the user has a trojan or virus on their PC which is key logging, it's very likely that if it's captured the user's VeriSign password, it's also captured the user's email address and password.

From this point onwards, the Hacker can sign in as the user and receive the following PAPE response:
http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical

There is a physical token associated with the account, it just isn't the user's physical token!

Currently, these responses are provided:

auth_time:2009-04-28T07:55:26Z
nist_auth_level:0
auth_policies:http://schemas.openid.net/pape/policies/2007/06/multi-factor http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical

Potential solutions

As stated earlier, the lost token use case is a valid one and it needs to be accounted for. It's an exceptional event, though, and relying parties would benefit from being able to detect and take action following the loss.

One way around the problem is to severely restrict the token recovery procedure, like potentially eliminating the email and only have an SMS type delivery. At least the SMS is out-of-band from the user's PC and so this significantly reduces the chances that a hacker can get hold of the One Time Password when it's sent through. This reduces convenience for the user and won't work for users that are using their mobile phone as the OTP token using VeriSign Mobile.

Another approach is to include in the OpenID response details of the token that was used to provide the One Time Password. This allows Relying Parties to at least detect that the user has changed their token and should kick-off a process of keeping an eye out for potential fraud. There's no way that the Relying Party can tell the difference between a 

On a protocol level, this would be communicated as an openid.pape.auth_level.<cust> response parameter, but the PAPE specification states "A custom Assurance Level definition MAY define additional subparameter values that are expressed within its namespace, although for reasons of simplicity, this SHOULD be avoided if possible."

Providing OTP token details in the response could constitute a leak of user information. Rather than providing the OTP's serial number, a one-way hash of it (or just some other arbitrary generated and stored identifier for the token) would be fine.

The exact scenario I'm picturing is Internet banking and my suggested workflow would be:
  • User is already a customer of Bank ABC and is interested in using his VeriSign credentials to authenticate with online banking so that he doesn't have keep remembering yet another set of credentials. ABC bank also has 4 additional pieces of "memorable information" for the user (e.g. name of User's first pet, place of birth).
  • User logs into Internet banking for Bank ABC using the username / password credentials that he's been using for a couple of years that were provided by Bank ABC.
  • While logged in, the User clicks on a link to associate their Internet banking account with their VeriSign credentials. Bank ABC redirects to VeriSign for authentication and insists on two-factor physical authentication forcing the user to enter an OTP token value. VeriSign responds with an authentication success and an identifier for the OTP token. Bank ABC stores the OpenID and OTP identifier against the user's account.
  • User happily uses their VeriSign credentials to log into Bank ABC for the next year or so, his Bank ABC credentials are no longer required.
  • User loses his OTP token and applies for a new one from VeriSign directly or a co-branded OTP token from Paypal. Importantly, he doesn't necessarily apply for a co-branded token from Bank ABC. The user might have 5 other bank accounts where he can use his VeriSign credentials but only has one OTP token.
  • User receives his new OTP token through the post from Paypal.
  • User attempts to log into ABC bank's online banking with his VeriSign credentials.

At this stage, ABC bank should be able to see that the user's OTP token has changed and can decide whether to:
  • Prompt the user to enter some of the "memorable information" they have on record.
  • Prompt the user to enter their original ABC bank credentials (this won't work, of course, for users who signed up with only VeriSign credentials from the start, but that's a different use case).
  • Ask the user to phone Bank ABC's support line and authenticate themselves over the phone to validate the change of OTP token.
The bank may choose not to do any of those things but it should have the option to perform a check.

Why doesn't this problem exist with all OTP token systems?

The difference is that if you have 5 bank accounts you have 5 bank cards. If you lose your HSBC bank card, it's HSBC that sends a new one in the post to you. That's not necessarily the case for the VeriSign OTP token. Any of the 5 banks or Paypal, or Verisign directly may issue the replacement token and won't notify any of the other banks.

Changing the OpenID PAPE specification

It looks like there already some proposals for extensions to the OpenID PAPE specification being considered. These extensions concern optionally specifying what type of authentication policy has been exacted on the user in a less general way than just saying "anti-phishing" or "physical token". It may be worth adding in a requirement to identify the token being used.

Actions that a user can take if their account is compromised

If a user has their account compromised then a hacker can potentially gain access to tens of systems with the same credentials. The OpenID account is much more difficult to steal than an individual website account, but the workflow that the user must follow when a breach has occurred should be defined. This section (when finished) will try to define this workflow.