Salesforce Two-Factor Authentication - A Test Drive
In a world of higher and higher security standards one of the best practices to implement is two-factor authentication. This is the method of adding a second factor to the username and password, where the password is the first factor. The second factor is usually done with a random and time based code, generated on an approved mobile device. Other implementations use one time pins sent via SMS at login. For these purposes we are taking a look at the Winter 15 feature that Salesforce launched, which we have been piloting for a few months.
The Setup
Salesforce’s two-factor is based on the traditional mobile application model, random six-digit numbers that expire after 30 or 60 seconds. The set up is as simple as creating a permission set adding the “Two-Factor Authentication for User Interface Logins” permission to it. After assigning that permission set to a user (You are using The Permissioner, right?), the next time they login they will be presented with a QR code which they can scan into one of the many two-factor mobile applications including Authenticator, Salesforce# and Authy. These applications all do the same basic thing, which is to randomly generate the six digit codes needed to login.
The Day-to-Day
For a user whose two-factor authentication is enabled, each time they login to Salesforce, they first put in the traditional username and password, then on the second screen are presented with a place to put in the code. This requires opening up the application on the mobile device and copying the six-digit code into the browser window before the time expires. Most applications show you how much time is left, blinking or turning the code red as it gets closer to expiring. For the most part, this is a simple process although it does require that you have your mobile device on you at all times (better not be charging in the other room, beside your bed, or out of battery). The feature also launched without the fine-grained controls seen in other implementations such as Google, which only require it every 30 days or when logging in from an unknown browser. The Winter 14 feature requires it every time you login, so closing out your browser and coming back 10 minutes later, you need to enter a code again.
Security at a Price
So while the increase in security can’t be denied, the downside is the extra work for the users logging in or that have a mobile device breakdown. Three features would make the current implementation just a bit easier to manage or even more secure. The first is to generate a set of one time backup codes, that would be saved in case of a missing or dead phone (vote on idea here). The second would be to add Touch ID support to Salesforce Authenticator for another level of security. This is something that the pay application Authy has built-in but it would be nice if Salesforce added it to their application. The last needed feature is to add more configuration settings for when the two-factor is needed. For example, require once a month or every time the IP address changes. This was addressed in part by the Winter 15 feature but isn’t a simple set of settings under setup, which is where it should be.
Overall the two-factor feature is much appreciated and with a little help here and there, could be ready for prime time. For those of you on Salesforce1 Mobile, yes you need to use the key code once on first login.
If you have been using Salesforce Two-Factor and have some experiences with it, post below, on our Facebook page, in the Success Community or directly @JasonMAtwood.
