Get the inside scoop with LoginTC and learn about relevant security news and insights.
December 11, 2013 •
In the latest version of our mobile apps for Android, iOS, and BlackBerry, we made a change that, at first glance, might seem like an odd decision for an app that is all about security. Starting with version 1.3.0 of the apps, users no longer have to enter their PIN to revoke tokens on their devices. Instead, there are simply a couple dialogs confirming that the user really wants to revoke the token, and explaining what will happen if they choose to do so.
While we were building the recently released Secure Remote Password upgrade, we reviewed the behaviour of the then-current app and noticed some room for improvement. When a user wanted to revoke a token, they were asked for their PIN as a confirmation. If the user then entered the PIN for the token, the token was revoked. However, if an incorrect PIN was entered, the user got a dialog indicating that “The PIN entered was incorrect.” and the number of retries left. That meant that if enough incorrect PINs were entered the token would be revoked anyway. The problem was, that PIN was supposed to stop someone other than the user from revoking the token in the first place. Clearly it wasn’t doing its job if someone could just enter 5 incorrect PINs to get the same result.
There’s a deeper problem here as well, and it turns out to be a security issue. People use the same PIN or password for different things all the time, and there’s no reason they’ll stop just because they’re using our product, as much as we’d like it if they did. A user might have multiple tokens on their device, perhaps even for domains controlled by different organizations. They may also have decided to lock them all with the same PIN or password.
Let’s assume that an attacker has gotten hold of the user’s phone, and wants to impersonate them by logging into a service protected by LoginTC multi-factor authentication. There’s a reasonable probability of PIN reuse if a user has multiple tokens loaded, so if the attacker can guess the PIN for one of the others, they’ve got a better guess for the token they’re really interested in. They might even be able to guess it before the 5 retry limit that will revoke the token and lock them out.
What’s the easiest way for an attacker to start guessing PINs, given access to the app with tokens loaded? In the old apps, it was to revoke some tokens, as an attacker wouldn’t need to even try to log into the corresponding services. With the new behaviour, revoking a token doesn’t give an attacker an easy way to start guessing PINs.
Next, we’ll consider a user who has forgotten their PIN. There may be a reset path, perhaps through their organization’s help desk, but until they reset the token and choose a new PIN, they can’t use their token to approve any authentication requests. The token is just sitting there on their phone, activated, and a potential liability. Perhaps this is a security conscious user, and they want to revoke the token right away to ensure it can’t be misused if someone manages to steal the phone and guess their PIN. Shouldn’t we be making their life easier, and letting them do the right thing? Of course we should.
With the new behaviour, the user can revoke their token right away, and then get a new token issued to them when it’s convenient. Think of it like cancelling a lost bank card before getting a replacement.
With the new apps, users no longer have to enter their PINs to revoke tokens from the app. Dialog windows prevent accidental revocations while informing the user what revoking a token actually does. This new behaviour also increases security, both by taking a tool away from attackers, and by making life easier for security conscious users who want to do the right thing.
We’re always looking for ways to increase security and improve user experience. With this update, we’re proud to say we’ve delivered both.