2FA (two factor authentication, multi-factor authentication) has been a subject I have been deeply interested in for over a year now. It started when I started at Flywheel, and had an opportunity to work on the team that need to implement a 2FA solution. While researching for the implementation, I hit several dead ends with searching for best practices on 2FA implementation, specifically from a developer perspective.
There was a lot of information out there that was just from a user’s perspective. Always turn on 2FA, use a strong password, don’t reuse passwords… Great advice! Definitely security practices that everyone should do, but not what I needed if I was going to design and develop a 2FA implementation for an application.
So when I was encouraged to try submitting a talk to a conference, it was with this idea I built my first talk upon. That it was important to know 2FA from both a user perspective and a developer perspective. We developers need to know how to protect our users, and since we ourselves are a user of some service or application out there, also to remember what good application security best practices are to keep ourselves safe.
Why do we need to worry about protecting our users?
Well there are a lot of vulnerabilities out there, and we can’t guarantee that an application can be 100% safe, but I think there are always ways to be more secure. Just think about some of the latest credit card breeches there has been *cough*Capital One*cough*. The latest rounds of sim card swapping (which we can cover later, but cell phones and cell security is definitely tied with 2FA), what happened with Ring and Nest and how not opting a customer into 2FA (or even letting them know very well about it) and enforce secure password policies for users made the applications more vulnerable. All of these were hard lessons learned about why 2FA is important.
Not to even mention all the trouble Reddit had with a 2FA hack
What can developers do to secure an application?
Enforce and encourage users to create secure passwords with a good password security policy.
This is the first step because 2FA can only help enhance security on top of a secure password security. This is an application’s first authentication step, so it needs to be as secure as possible. By having a policy that encourages long random unique passwords (going for that high entropy), this helps users create more secure passwords.
Yes that XKCD comic about passwords everyone knows! Why this helps is because of entropy
You can’t create the password for the user (well in some cases, password reset for one, but you could apply this same policy to those generated passwords too) but you can make it easy for them to create strong ones for themselves, and maybe give them a bit of encouragement too.
Don’t limit characters sets, this will account for lower entropy. Same applies for length, don’t limit it because it will cause lower entropy (easier to guess) passwords, but do enforce a minimum length. For an examples of a secure password policies but also one that is flexible, check out GitHub. If you want to read more in depth study about measuring password policies and how they affect the user’s created password, check out this onefrom Carnegie Mellon.
Decide whether to buy or DIY with an application’s 2FA solution
To create a solution yourself or to integrate with a vendors solution is something that should be decided early on in the planning process. There are pros and cons with either decision, but just know that there are options are out there.
For the DIY route, there will be some extra step to consider when implementing your solution. Will 2FA be opt-in? If it is is not mandatory how will authentication be enforced on webpages? Will the 2FA verification code be required on every log-in/ip address/browser?
Consider how your users make use of the application. Will they usually have one account or multiple accounts? If they have multiple accounts, how will this policy affect them? If it is too frustrating, and frequent, receiving the verification code, you do run the risk of lower adoption rate (which isn’t usually great as-is even for places like Google) so it is important to help balance user experience.
For the buy route, there are many vendors and solutions out there to consider. Such as Okta, DUO, Ping, Knomi, and iovation.
Each should be evaluated for your needs (is SSO a requirement, do you need a support experience, how many users do you have) all of these will affect the pricing of the solution. If you aren’t paying in development time, you will be paying for the solution with, uh, actually currency. Typically the fancier the solution set, the fancier the price tag. But these solutions can typically provide features that might have been way outside a typical in-house 2FA solution, take for example biometrics and SSO (single sign on)
Rate limiting is key to preventing or limiting scope of brute force attacks
If you are going the buy route, make sure there are settings for limiting the amount of times a user can put in an incorrect password. In addition, make sure of amount times an incorrect 2FA verification code can be entered is limited too. If you are creating your own solution, make these as part of your log-in and verification code process. This will help limit scope on any of those nasty brute force attacks that might occur.
Get user buy-in
Users want the application to just work, they can log-in, use the application and everyone is happy. It is a bonus if it is secure, but if that security gets in the way of usability, guess which one usually gets dumped to the ground. Security that’s what. Typically 2FA is also an opt-in process, so if you want users to opt-in to an optional security practice good design and usability practice have to be kept in mind.
EVE Online did a great job of this balance. For them, their user’s might have multiple accounts, some even have hundreds of accounts. So enabling 2FA for their users was not a popular option, when they would have to be prompted for a 2FA verification code with each account login attempt. So they went the route where a user could share a 2FA key with all of their accounts, and this flexibility in their architecture helped boost user adoption. There was a talk from NDC London covering how EVE online protects there users with programmer Stefán Jökull Sigurðarson. When the link for the video comes online I will update with it.
For admin/super users 2FA is not optional , but a requirement
Looking back at Reddit, and the sim swapping scams, the focus of these attacks were the admin users. That is because they are the users that have the most amount of privileges. They have escalated privileges that a typical user never sees, so they are the ones that should be considered most vulnerable. So if you want to protect them, enforce 2FA on their accounts, and then if possible enforce at least TOTP authentication or better yet token based authentication.
So I will leave you with this my friends, use 2FA, and if possible don't use SMS 2FA 😏
Top comments (0)