Resources

5 Reasons to Outsource Your Authentication Like You Do Your Credit Card Processing

November 28th, 2016   /   Posted by   /   Topics: Blog

authentication

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:

  1. Designing these systems is not our core competency – we’re good at researching languages and frameworks to design static analysis tools that help fix them
  2. In accordance with #1, development time spent on a payment gateway should be minimized
  3. Codiscope does not want to absorb the financial and logistical overhead of storing credit card information and PII in compliance with PCI DSS (your company probably doesn’t either!)
  4. If there is any sort of data breach on the third party’s side, it’s “their problem.” If there is a data breach on our side, it’s our problem, but the amount and type of data breached will typically be far less impactful
  5. The tooling that products like Swipe provide also includes user-level benefits, such as improved usability and performance

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.

1. The Cheapest Way to Protect PII is to Not Store It

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.

2. The Easiest Way to Implement Authentication is to Not Build It

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.

3. Google and the Others are Probably Better at Building Secure Authentication Systems Than You Are

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.

4. If a Breach DOES Happen, The Impact is Far Less Significant

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:

  1. Google has a fantastic security response team, likely to be matched by the other top federated identity providers
  2. Google’s users are not necessarily your users. If there is any sort of breach in Google’s user data, there will not be a 1:1 correlation between their users and yours — there’s even a nonzero chance that none of your users would be infected!
  3. Google can typically move quickly to mitigate and resolve the issue, at no additional cost to you
  4. There are limited legal implications — you are likely protected from any direct litigation that might occur

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.

5. For Users, Third Party Authentication is Often More Trustworthy and Usable

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.

You Can’t (Don’t Want to) Handle the Auth!

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.


Developer Tools for Security

The Codiscope content team writes tutorials sourced from our technical staff and commentary based on trending topics in software development. We usually choose topics that we think will be interesting and informative, but we're open to suggestions. Tweet us with your topic ideas!

Read more by Codiscope