Two-factor authentication, password + device, seems to be increasingly mainstream among consumers with products like Activision Blizzard's Battle.NET authenticators. However, I am curious what the difference in level-of-security between a stand-alone key fob and mobile phone.

Given the connectivity of a mobile phone, it seems vastly more vulnerable than a device with a button and display which would need to be disassembled to gain access (but even with direct hardware access, is the key protected?) Given that both add some additional security and the pool of people who opt not to use it is still large (if not the majority), this is probably a non-issue in the Battle.NET case, but generally, how do they compare?


5 Answers 5


Relative to the idea of multi-factor authentication, any additional factor beyond something you know adds an additional level of complexity for someone to gain unauthorized access to an account. The second factor that many organizations use is something you have be it a fob of sorts (event or time based OTP), smartcard (HSM), phone (SMS, call), or an application (in the case of "soft" tokens (either an app that's installed on the phone or computer)).

Key fobs have become popularized but the security industry has seen that exploitation is possible (do a search on RSA and you'll see why). Key fobs can be broken if someone breaks the system. Instead of disassembling each token out there, an attacker broke into RSA and gained access (though I don't recall if this was "proven" or not) to the secret sauce that makes each token unique. Similarly, smartcards and USB tokens can be broken if the adversary successfully attacks a higher level in the tech stack or process to ensure each smartcard is unique. Mobile authenticators can be broken (same way as with RSA or via other means), but the idea hasn't ever been to block 100% of the attacks, which is cost prohibitive for most organizations. The goal is to implement preventative (where possible) and detective technologies such that unauthorized access attempts are blocked or identified where successful. To that end, mobile and hardware fobs still add value.

Perhaps to your point, mobile authenticators likely provide sufficient protection for Battle.NET users. Fundamentally, they're protecting against users stealing money or gaining access to someone else's account. In the event someone is really interested in breaking the system, hardware or mobile authenticators (or even biometric) layered in third and fourth factors may not be sufficient. So from a cost perspective, mobile authenticators are cheaper to deploy, simpler for users to use, and provide an additional layer of protection. Hardware authenticators are more costly for both the user and game provider to implement and maintain.

To sum it up, mobile is good enough for the use case.


It's a trade-off, both have different advantages and weaknesses. IMO mobile authenticators are much stronger than classic tokens in practice, if built correctly.

Their great advantage is that they can display what you're authorizing in a place a trojan on your PC does not have access to.

For example with online banking it might display the amount transfered and the target account number.

For gaming it can distinguish simple logins for playing, and high risk operations like changing password, email or disabling the authenticator.

Their weakness is that it's easier to compromize a smartphone than it is to compromize a simple token.


Given the connectivity of a mobile phone, it seems vastly more vulnerable than a device with a button and display which would need to be disassembled to gain access (but even with direct hardware access, is the key protected?) Given that both add some additional security and the pool of people who opt not to use it is still large (if not the majority), this is probably a non-issue in the Battle.NET case, but generally, how do they compare?

Your question really is: "Is a desktop application that generates a security token as secure as a physical device that does the same"

The answer to this question is: it depends

Recently it was discovered that the RSA Windows application that generates a security token has security flaw because of not only how it works but because it uses a security feature built into Windows to protect the token data. In order to keep this statement short, it was discovered that the token can be copied, which allows future tokens to be generated.

This flaw also exists in some versions of mobile authenticators. For instance It is possible to "duplicate" the Blizzard Mobile Authenticator and write a desktop application if you root/jailbreak your Android/IPhone and copy the serial and secret token. This is because the file that contains this information at least on Android is not protected that well ( shift operation ). In the case of a jailbroken IPhone basic security features in the operating system can be disabled, which normally cannot be disabled, in order to do something similar.

In the end an application on a closed system like a mobile phone is a great deal more secure then a traditional desktop application.

I consider Android, Windows Phone 7.x, and iPhone to be closed systems

Some of the problems with the RSA Windows desktop application likely stims from their earlier compromised based on how the algorithm works

  • 1
    It seems here you're addressing desktop vs. smartphone implementations. While this information is useful, it is not the comparison that Nick seems to be looking for. He wants to know the security level difference between desktop- or smartphone-based authenticators and token-based authenticators. i.e.: RSA SecurID token vs. SMS message.
    – Iszi
    May 23, 2012 at 16:33
  • @IsziRoryorIsznti - I admit I did group the traditional desktop application and mobile application into one group ( mainly in his specfic example dealing with Blizzard's authenticator it applies ) as the physical device generates a 6-digit code instead of 8-digit code. He wanted to compare an application to the physical device. So your conclusion that he wants to compare the RSA SecureID to SMS messages is incorrect.
    – Ramhound
    May 23, 2012 at 16:55

I assume you're talking about a mobile device of some kind which displays or transmits a one-time password derived from a shared secret and either the time or a shared counter. Such devices fall into three categories:

  • A standalone device with a display.
  • A standalone device with a USB (or other) interface which must be accessed via a computer.
  • A general-purpose device such as a mobile phone.

The relative security of the various device types depends on your threat model.

The most obvious threat is that an attacker steals or borrows the device. In this scenario, it doesn't matter how hard it is to extract the key from the device: the attacker merely needs to be able to use it in the usual manner.

The attacker only needs to extract the key if he wants to be able to authenticate later, but wants his access potential to go undetected. With this goal, the attacker must gain temporary access to the device, extract the key, then return the device to its owner. After this, the attacker can go undetected as long as he does not make too frequent connections to the account if the OTP is derived from a counter, or indefinitely if the OTP is derived from the time.

The security of the key against an attacker with physical access only matters if you want to protect against hidden access. A standalone device may have better protection against physical attacks than a mobile phone, however such protection costs money, and authentication tokens are usually a low-cost item. High-end mobile phones do have some limited protection against physical attacks; for example, it is not so easy to extract data from an iPhone. Most mobile phones furthermore contain a SIM card, which is tamper resistant; some OTP providers can install the OTP key on the SIM. Some mobile phones contain an embedded secure element, which is similar to the SIM but controlled by the device manufacturer instead of the network operator.

Most OTP token devices display the OTP at the press of a button. A mobile phone has the opportunity to require authentication (PIN, pass-gesture, …). How much this improves security depends on whether the phone is stolen unlocked and how strong the authentication is.

There is a threat where mobile phone gets a slight edge: that the user would lose the token. This is in addition to the usability benefit of having a single device. A user who has many OTP tokens is more likely to lose one of them, or to not notice its theft for a while, than he is likely to miss his mobile phone.

A different threat is that of malware on the device. Standalone devices are pretty much immune, assuming they were clean when the user got them. Mobile phones are vulnerable; an attacker who can install malware that retrieves OTP tokens gains remote access to the one-time passwords. Devices without their own display are similarly vulnerable to malware on the computer they are plugged into, though this malware will only be able to obtain an OTP while the device is connected.


Basically, the way I see it With a Physical token from RSA, there are only a few places an attacker can get the Seed file to be able to duplicate the token in software. #1 from RSA, #2 from wherever you stored the media that RSA shipped to you, and #3 the authentication server.

With software tokens from RSA you can add to that list the PC or mobile phone that is running the software token.

With TOTP (Google authenticator style soft token) there is the authentication server and the PC or mobile phone that runs the token app. The authentication server generates the seed code itself, so there is no 3rd party like RSA for the attacker to try.

That said, I am not a cryptographer, so I am not qualified to talk about the relative strengths and weaknesses between Google style TOTP and RSA's algorithm. (or any one else's)

  • Actually, now that I think of it, in the RSA hard vs soft you can subtract the RSA head office and media when you add the mobile to the list of places that can be compromised. RSA's softtokens are regenerated at the authentication server too. If I remove token from a user and assign that soft token license to another, a new seed is generated, so softtoken codes sent by RSA are just licenses to generate codes that work with their software. May 31, 2013 at 14:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .