App Security: To Build or To Buy? – Part 2: The Pitfalls Of Developing Your Own 2FA
This is the second article in the 3-part series: App Security: To Build or To Buy?
The role of programmer has changed dramatically from late 1990’s when they wrote nearly all of the software code for their applications. Today, instead of building an entire application from scratch, new software is built on platforms, and leverages existing frameworks: layers and layers of software, with built-in functionality to handle networks, databases, user interfaces, and more. So much progress has taken place in software development, that you can now put together a simple web-based application, with a database, application server and a whole framework for writing the user interface, within a matter of hours.
Programmers used to just write code, but developers—who do still write code—build applications, choosing a platform on which to create their solution. These platforms are built and maintained by a new group in the software world, called DevOps. Other services, provided by other vendors, are integrated into the platform to increase reliability, scale and implement core functionality.
What Would DevOps Do?
So what does DevOps do when they need to monitor the state of the application? What do they do when they need to ensure your service can scale when you acquire more business? How about when they need to ensure your application is using the most user-friendly and secure two-factor authentication? For all of the above, the answer is to — like other aspects of your business software platform — buy and integrate a solution. Buying these core services allows developers to spend their time working on the functionality that makes your service valuable. It might seem like a costly route, but building it yourself is a lot more expensive and risky.
Just as the role of programmers has changed over the last 10-20 years, the nature of how software is delivered has also changed. Cloud-based software is delivered via APIs that are easily integrated into your applications and solutions. This results in the best of both worlds. You buy the API and then build it into your apps.
When it comes to authentication, you could incorporate 2FA into your application by building it all yourself. Unfortunately, you’ll need to ensure you can deliver a token or one-time password (TOTP) to an increasingly global audience – many of whom will not have a smartphone that can run an app. A great way to get TOTP to the end user is via SMS, which nearly every mobile phone supports, but now you need to find an SMS provider with good global coverage? You’ll also have to deal with building in fail-over logic, user phone losses and number changes, and text-to-voice capabilities for those who can’t access SMS.
To avoid having to deal with these issues, you could use a 2FA application that someone else has created. Google was one of the first companies to offer a 2FA service to their millions of users. The Google Authenticator smartphone app supports the TOTP standard, so you could just tell users to install that.
- But what if you want to brand the user experience?
- How do you add your company logo so end users are assured they are using the right token for your website?
- And what if the user wants to use more than one device?
- Do you require they go through the same set-up process each time they want to use a device for 2FA?
If you want to be a really modern app, you’ll want to take advantage of improved end user experience by implementing a push notification based solution for security. But implementing such a feature requires understanding how the Apple Push Notification Service (APNS) and the Google Android Cloud Messaging (GCM) services work. It’s significantly more work, many of the free TOTP authenticator clients don’t support push notification, and you still need to consider implementing a token based solution so that users without smartphones or cell phone connectivity can access your application. Most likely, you’ll need to develop your own 2FA client with both push and TOTP capabilities.
All the above options result in a lot of code and dependencies. But implementing them often exposes you to the inner workings of security protocols. And if your developers are not experts in security software development, or if you make a mistake in this part of your application, you’ll impact the front door to your business. If the 2FA solution you implement breaks, nobody can login. If it has a vulnerability, it’s an avenue for a security breach and no longer a security feature.
In short, developing your own 2FA solution is not simple. It requires specific knowledge and can take significant time to implement. And since specialist security software developers can be hard to find and expensive, there ought to be an easier solution.
Get Our Free White Paper
Learn more about avoiding the pitfalls of developing your own 2FA: Why You Can Buy Your Application Security And The Build With It
Next week: Part 3 – Get Total Control Over Your 2FA Implementation