Using mobile devices — smartphones, tablets and notebooks — to access an organization’s computing resources remotely continues to surge in popularity. While mobility is convenient, it can impede security  by creating weak points that attackers can exploit to gain access to sensitive information. Therefore, most experts recommend employing some form of two-factor authentication for remote access by mobile devices.
Two-factor authentication can be a real headache for users and organizations alike because it adds complexity to an organization’s authentication processes. And if implemented poorly, two-factor authentication may not be much stronger than single-factor authentication, while consuming considerably more time and resources.
Here are some tips for designing, implementing and deploying workable, secure two-factor authentication solutions for mobile devices.
Think about all the different types of mobile devices used in the workplace: all the different brands of notebooks, smartphones and tablets, not to mention both organization-issued and personally owned devices.
Some users may have a notebook supplied by the organization, along with a personal notebook, smartphone and tablet. It’s just not realistic to ask those users to employ a different two-factor authentication method for each device. Imagine carrying a few cryptographic tokens and memorizing four passwords or personal identification numbers, then trying to remember which tokens and PINs apply to which device.
For the sake of usability, carefully consider having a single remote authentication solution for all mobile devices. Organization-owned notebooks may be the exception to this, particularly if they have built-in two-factor authentication capabilities such as smart card or biometric readers. Otherwise, operations will proceed more smoothly if multiple two-factor authentication systems can be avoided.
Mobile devices, particularly smartphones and tablets, tend to lack the security features that other computing devices have. Yet many two-factor authentication solutions rely heavily on the security of the mobile device for the security of the authentication.
For example, “soft” cryptographic tokens store a shared secret or cryptographic key on the mobile device. On many devices, this secret or key is largely unprotected from malware or even human discovery. Ideally the secret or key would be stored in a Trusted Platform Module (TPM) within the mobile device, but few mobile devices today support TPM. Therefore, it may make sense to implement a two-factor authentication method that isn’t so reliant on local storage — for example, image-based authentication.
Network security is another important consideration. We largely take it for granted that cell phone networks aren’t being monitored, but attackers certainly have the capabilities to do so. This means that two-factor authentication methods that send sensitive information in clear text, such as those that send one-time passcodes through SMS messages, may be exposing that information to attackers.
Consider the threats against remote access methods and, if necessary, strongly encrypt all sensitive information being transmitted to or from mobile devices.
When using two-factor authentication, rather than authenticate both factors simultaneously, first authenticate one factor. If that’s successful, authenticate the second factor. This can prevent brute force attacks, denial of service attacks and other attacks that involve multiple login attempts.
For example, if the first authentication factor is username/password authentication and that’s susceptible to lockout, then an attacker could simply spew username/password combinations at the remote access gateway and lock out legitimate user accounts. If the other factor is first, an attacker will have to provide it before they can even attempt a username/password authentication.
That being said, username/password authentication should be resistant to brute force attacks and denial of service attacks. An effective way of accomplishing this is to implement an increasing delay between authentication attempts. For example, after an authentication attempt fails, make the person wait two seconds before trying again. If the next attempt fails, then double the delay time to four seconds; if there’s another failure, double again to eight seconds. This prevents the account from becoming locked out while minimizing the number of authentication attempts that can be made. Monitoring software should detect continued attempts and notify an administrator for intervention.