Posted by Synopsys Editorial Team on November 28, 2016
You may have noticed that we don’t create credit card processing solutions here. We use what already exists, as we do for authentication services, and there are some good reasons for that:
You should rely on a third party authentication provider, too, rather than build your own. We’ll walk you through our rationale, but largely the evidence points out that outsourcing your authentication like you do with your credit card is, more often than not, cheaper, easier, safer.
Let us be very clear up front. These systems are not perfect, and using them does NOT entirely absolve you of any security responsibilities. Many of the login providers have strong guidelines and best practices around implementing their systems securely. What these authentication systems do is simply make the job significantly easier.
Now that we have that disclaimer out of the way, here are some reasons why you should consider outsourcing your authentication.
Base-level authentication requires you to store at least a user name and a password hash. Email verification obviously requires email, and then two-factor authentication requires a mobile number or some other trusted contact information. You see, even if your authentication workflow is secure, you have a mother lode of PII waiting to be gobbled up by an eager hacker.
Here’s something crazy: even if you’re diligent and use a relatively secure hashing algorithm like SHA-256 to encrypt and store your passwords, weaker encryption in other parts of your authentication flow can still make you vulnerable. This was Ashley Madison’s problem, among other things.
When working on a new project, you might have a thought like “how many times in my life do I have to implement a ‘login’ flow, or a ‘reset password’ flow?” This is not glib or whiny — this is a valid concern. The focus of your staff should be maximized on your core competency, not reinventing the wheel.
Luckily, this is one of the problems that is solved when you switch to something like Google Auth. All of the security, protection, and authentication happens on Google’s end and users are protected by things like their two-factor authentication. Google basically passes you back a federated identity — all that’s left for you to do is authorize it on your system.
In addition to simple authentication, some tools like Firebase provide authentication as well as features like password reset and email verification.
If you’re not working within a vertical or an organization where managed data storage is an absolutely necessity, you can likely trust that companies like Google and Facebook have more resources at their disposal to keep your data safe than you do.
A very important note: some authentication systems are better than others! Be mindful of this as you move forward. For example, LinkedIn and Google seem to be best in show, while Twitter lags behind. Comparitech has a great comparison of the systems on their site.
We should always be thinking about and planning for the worst, so what happens when there IS a data breach and you’re using Google Auth for your application’s authentication?
If the breach happens on Google’s side… well, that’s likely a much bigger problem. You can be confident in a few things:
If the breach happens on your side, it’s still very bad. The good news is that, by outsourcing authentication, you have reduced the amount of PII that would have been compromised as a result of the breach.
If I’m shopping for a deck of cards, I don’t necessarily trust “tomsmagicshopboston.com” but I do trust “PayPal.” The same applies to your authentication. Your users may not know it, but you’re asking them for a lot of trust when you supply a login. Most (but not all!) users will see Google, Amazon, Facebook, etc. and they will recognize a trusted brand that they know and are comfortable with.
Plus, the speed increase is wonderful for usability. Need to register? Click on the Facebook logo. Need to log in? Click on the Facebook logo.
It’s not cutting corners if you don’t create a full soup-to-nuts authentication flow from scratch. As you can see, using third party authentication platforms is good for you, good for your organization, good for your users, and overall a solid architectural choice.
We should reiterate that implementing one or more of the providers doesn’t make security considerations go away, nor does it even make your application safe; you should still be as diligent and mindful as ever… You’ll just have more time and energy to be focused on securing the rest of your application.
Get the latest Software Integrity news, thought leadership, and more.