1

Consider such two factor authentication on web site: say when user enters username/password on web site - and receives SMS on mobile phone number. For attacker to access this he must know your username/password - and also steal your mobile phone.

But if I want to protect mobile phone application this way, I think the second factor is not useful anymore. Because in order for attacker to access your mobile phone application, she has to steal the phone anyway - now if she stole it AND knows user name and password he can access your mobile phone app.

So I think the two factor authentication scheme I described above doesn't bring much security when used for mobile phone application; Of course that is not the case if you use this method for authenticating with web site. Am I right?

So what second factor is typically used to protect mobile phone applications? (besides password).

  • Why would I need to steal the phone anyway? Without 2FA if I already know the username and password, all I need to do is have any phone which runs the same app as your phone does. – jjanes Feb 13 '15 at 19:23
  • @jjanes:yeah that's the point AFAIC it doesn't work with other phone (the authentication) – user68288 Feb 13 '15 at 22:29
3

The point of two-factors authentication is to pick two of the following:

  • something you are (biometrics, ...)
  • something you know (password, pin, ...)
  • something you have (token, phone, ...)

If you want to protect something that is locally store on a phone, you obviously don't ask for the user to have the access to the phone. You can still use 2-factors authentication by either choosing a "something you have" that is not the phone (example a token), or switch the criteria to "something you are" (example fingerprint). For some reasons, the biometrics are not necessary the best way to go, because it generates some problems.

Eventually, some have tried to use new criteria like "someone you know", for example by issuing a token from an already authenticated session, to connect a new device. Mozilla Firefox did that for a time to synchronise the preferences between browsers.

1

Let me bring you pack a few steps there, Any attacker can intercept and change the data leaving a website allowing them to change the phone number to something else, it's not that hard at all, I have personally been given permission to test this as well, it does and can happen all the time with little trace.

1

(Disc: I work for WiKID Systems).

It's a good question - especially as we move into SSO across mobile and desktop. I think it's time to move past the typical 'factors' and think about how they are implemented and how that impacts risks. (I think there's also questions about what info you want to be responsible for holding.)

WiKID requires a passphrase to open the token and then a PIN to get the OTP. The attacker need to put malware on the phone and capture that info and copy the private keys embedded in the token. Doable but a different risk. Compare this to TOTP or SMS where you just need an unlocked phone.

That being said, if you are already asking for a password I think you are doing as much as you can with SMS. Note that SMS is basically just unencrypted email that goes to a phone so there are lots of ways to attack it.

  • " Compare this to TOTP or SMS where you just need an unlocked phone." -- this is not true if in addition to SMS I ask the user also about username/password right? – user68288 Feb 13 '15 at 13:22
  • So at WikiD you have two passwords(one for token and one for OTP)? How is it more secure than SMS+password on mobile phone? – user68288 Feb 13 '15 at 13:28
  • Right - you ask for the password as you would also have to do with TOTP because it is only one factor. Because WiKID takes the PIN and encrypts it to get the OTP both factors (PIN and private key) are in the OTP. – nowen Feb 13 '15 at 15:17
  • is it more secure than SMS+usename/password? Also one question: if I use PIN authentication such that PIN gets accepted only from a specific mobile phone (e.g., if someone steals PIN and uses it from her mobile phone authentication will fail)-how would you describe security of such scheme? and compare say with SMS+username/password – user68288 Feb 13 '15 at 15:19
  • well, the key difference vs sms is the encryption which we control (TBC: the keys are generated on the device) vs SMS where the carrier is supposed to encrypt but who knows. SMS could be intercepted at the carrier, or an attacker could take over a user's cell account via the carrier's website. You are relying on the carrier's security, weakest link, etc. I also don't want any info that I then have to protect. I would hate to lose my customers cell phone numbers to spammers. – nowen Feb 13 '15 at 15:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy