0

If I'm using something like Authy for soft tokens for my users, and they log into the web application on the mobile device itself, haven't they just lost the benefit of 2FA (ie loss of the mobile phone by itself may result in compromise of both factors)?

If so, is there any reliable way to prevent users authenticating on the same mobile device (or even on any mobile device)?


edit: I've discovered that Authy (at least on iOS) allows you to set an access PIN, which helps for trusted users. Now if there was a way to enforce that a PIN is set I'd be completely happy.

1 Answers1

2

Yes, it loses some of the protection since it fails to protect them if the device is thoroughly compromised. It still, however, protects against any number of limited attacks.

For example, if they are configured to connect through a proxy that can strip the encryption, the 2FA will remain safe. If the password DB is compromised somewhere that they used the same PW, the 2FA will remain safe. If they use the account on another computer sometime and that computer is compromised the 2FA will be safe.

A thorough compromise of the phone is a failure case, but it is only one of many possible failure cases. It is worth advising the user that it is ill-advised to login on the same device as they use for the 2FA, but ultimately, it still does provide significantly more benefit than having no second factor would.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
  • Good points. I've also discovered this subject has been alluded to here: ["Transaction performed on the phone."](http://security.stackexchange.com/a/14684/2752) –  Nov 21 '14 at 15:28
  • It also depends on the token's protections and the type of token. Amazon, Google and some other display the OTP on open. WiKID requires a token passphrase and a PIN prior to OTP delivery. – nowen Nov 21 '14 at 15:30
  • @Nowen - which would still be entered on a compromised device and thus provide 0 to almost 0 additional security. It only prevents a non-persistent remote exploit of the device, which is a very, very small use case of protection. More thoroughly, it only helps you when there isn't key logging on the device, in which case the password for the site wouldn't be compromised and the 2FA token compromise wouldn't matter. There is literally almost no situation (if any) that WiKID's password on the token helps anything. – AJ Henderson Nov 21 '14 at 15:49
  • 1
    @Nowen - oohhh, that's YOUR product that you handily didn't disclose your affiliation with in the comment. Please tell me you are at least using a randomized GUI pin entry that doesn't link to key press events so that it is protected against basic loggers. (Which would be the reason I put the (almost) in the above comment.) Otherwise, the feature is completely worthless (and actually a hindrance to users). – AJ Henderson Nov 21 '14 at 16:06
  • Sorry @AJHenderson I usually do as you can see by looking at my posts and it's my bio. Busy week. We have one version with a randomized PIN pad that the Admin can require (available on the open-source version). In reality, if there's malware on the device, the game is over. They will have no need to go after credentials as they can get data. – nowen Nov 24 '14 at 15:04
  • @nowen - fair enough. – AJ Henderson Nov 24 '14 at 15:06