Authentication vs. Encryption

Understanding the merits of authentication as well as its vulnerabilities, and how it compares to encryption

Author profile picture
  • 7 minutes

What is Authentication?

Overview

Authentication is a process by which an application attempts to verify that a user is who they claim to be. It is effectively a permissions checkpoint, and a user is not allowed to proceed unless authorized by the application. Authentication comes in many forms, most commonly as a login with a password or PIN number. An authorized login allows the user to perform some set of protected actions, such as accessing an account or viewing some sensitive data. Other flavors of authentication include email confirmation links, SMS codes, or dedicated apps such as Google Authenticator, Authy, or Duo. In many cases, more than one form of authentication must be completed in order to gain authorization such as a Two-Factor Authentication (2FA) or Multi-Factor Authentication (MFA) scheme.

With just a single form of authentication, such as account login details, a user is susceptible to an attacker gaining access to their account maliciously. They can do so by acquiring their login directly, brute forcing their password, or performing a phishing attack, to name a few methods. By combining multiple forms of authentication, such as login credentials with a text verification code or an authenticator app, the attacker must compromise multiple separate devices or accounts owned by the user, and possess online access to them in order to gain entry.

By requiring multiple forms of authentication, an application should be able to provide extremely strong security against an attacker gaining unauthorized access by way of compromising a user’s login. While this is a significant win for individual account login security, authentication alone does not protect against large-scale data breaches, regardless of the individual’s use of multifactor authentication.

Weakness

The key weakness of authentication is that it is only a permissions check performed by or on behalf of the application, as its way of protecting against unauthorized users using the application. What it does not prevent against is the application itself being compromised. Namely, if an application has access to a database containing sensitive information, an attacker who infiltrates the application has the same capability. They could view the database freely, unconcerned with any user account login protections which might exist. This is precisely how a single data breach event can be responsible for the loss of millions of records despite each user having their own login.

At its core, authentication operates under the assumption that the application itself is secure, has not been compromised, and will not be at any point in the future. Unfortunately, the ever-growing number of cyberattacks we’re seeing shows this to be faulty, as even some of the safest and most security-paranoid systems continue to be breached. When we cannot rely on the security of the host application, we must turn to encryption (specifically end-to-end encryption) for keeping users’ accounts safe.

Why encryption is different than authentication

Using only authentication, an application simply grants users access to raw data it stores after verifying a login. On the other hand, encryption actually protects the data itself by storing it in a format which is unreadable to anyone without the proper key. Specifically, end-to-end encryption ensures that only the user possesses the key capable of unlocking their data, and not even the application itself can access stored data of its users offline. For more on different types of encryption, read our blog post “Why should I encrypt my database?”.

By storing the data encrypted so that not even the application can access it until the user is logged in, the application is no longer at risk of being compromised and having its sensitive data leaked. Instead, each individual user’s account login must be individually compromised in order to gain access solely to their account. In this format, authentication becomes an excellent supplemental tool to ensure that a user’s individual account is only be accessed by who they claim to be, while the system also remains protected against an application-scale compromise.

Recent breaches

A number of recent data breaches and vulnerabilities highlight the shortcomings of applications which do not utilize end-to-end encryption, even despite having MFA/2FA enabled:

  • In July 2020, some of Twitter’s employees were compromised, granting attackers access to internal tools - this gave them the direct capacity to post on behalf of any account, without requiring their login/password credentials1
  • In September 2021, GoDaddy’s WordPress hosting environment was breached, exposing customer’s admin passwords, database credentials, and SSL private keys of up to 1.2 million users2
  • In March 2019, Facebook revealed that it had mistakenly stored tens to hundreds of millions of users’ passwords in plaintext, accessible internally for years before it was discovered - fortunately there was no known compromise or abuse of this data3

It is clear that even large-scale and seemingly robust systems are routinely vulnerable to compromise, and are often irresponsible with sensitive data. This leaves end-to-end encryption, and thereby not having access to sensitive data in the first place, as the clear choice for anyone who is serious about keeping their users’ information secure.

Beyond encryption, even 2FA and MFA themselves are not immune to compromise. A recent breach of Twilio was leveraged to obtain one-time passwords (OTPs) that compromised Okta customers who were actively retrieving the codes over SMS4. This highlights both the importance of requiring multiple, separate forms of authentication, and cautions against relying on the integrity of a single third-party authentication as the source of truth for a login. This again reinforces the necessity to supplement authentication with encryption.

Where does Bunkyr fit in?

If encryption were always easy and practical, there would be no need for this comparison in the first place - everyone would be using encryption as a default. However, the reality is that adding encryption (especially end-to-end encryption) comes with a number of significant drawbacks to an application and its users.

End-to-end encryption introduces significant engineering complexity and overhead to developers of an application. For users, it brings hassle to their experience, and also comes with the added risk of losing all of their data. In an end-to-end encrypted system, the users are responsible for maintaining backup access to their account (such as seed phrases) which can be easily lost, in which case not even the application nor its developers can recover their data.

With Bunkyr, applications can adopt end-to-end encryption without burdening their users, by maintaining traditional and simple login flows with the help of a social sign-in like Google or Facebook. Under the hood, Bunkyr turns these standard social sign-ins into a robust, distributed recovery option without any extra work from the user. For the developers, all it takes is a few calls to our lightweight API to get recovery with Bunkyr up and running. Now, applications can give their users the streamlined experience of an authentication-only system without having to sacrifice encryption.

Learn more about the Bunkyr API through our docs or schedule a demo to see how you can get started!