PKI in two-factor authentication

You don’t need PKI in two-factor authentication — here’s why

Certificates usually feel good, right? They mean you’ve earned something. In the digital world, that often equates to access — verification that you and your collaborators are who you say you are. But certification is dangerous for online security. On the surface, it might look safe, yet there are many risks within a public key infrastructure (PKI), the mainstream method of checking your identity. It’s the basis of two-factor authentication (2FA): giving a username and a password, then confirming it with a one-time password (OTP) from a third-party authenticator.

However, PKIs are far from the best way to protect and verify your user credentials. When you realize what’s at risk, that good feeling vanishes. Typing a password and clicking “log in” seems as perilous as dangling your house key on a string to a stranger.

For a while, PKI has been the norm in 2FA and multi-factor authentication — for good reason. Yet other security solutions are showing why it’s insufficient and outdated. Today, you don’t need a digital certificate. We’re the proof. And when you make the switch, you’ll never go back.

An introduction to PKI security

So, what is a public key infrastructure? How does it work and why is it popular?

Whenever you use a digital device to make a login attempt, that information (password, username) has to stay secure. This is what encryption is for. Encrypted data is scrambled and senseless until you have the key to decrypt it. Each key is a unique combination of numbers, which are decoded when they’re passed through a cryptographic algorithm. In short, the details you enter and submit are private unless someone can break the code.

PKIs allow these keys to be distributed on a massive scale. Yet aside from hiding your data, they also check your identity. Two keys are generated — one public, the other private. Together, they confirm that a particular user is trying to access an application, cloud drive, IoT (Internet of Things) device, CMS, in-house platform or anything that requires a password or secure connection.

The PKI security model

Whenever someone logs in, they generate a public key. You, the owner of the web server, have a private key, which is used to confirm the public key’s owner. When these keys are exchanged, they’re meant to match and produce a digital signature. We call this “asymmetric encryption”. It’s like someone flipping through a phone book and finding a name beside a number.

The certificates it depends on

For the key exchange to work, it needs a certificate. Independent certificate authorities (CAs) provide the mechanism with which both keys interact. A CA issues certificates to the server owner, proving they’re legitimate. Every request and piece of metadata is stored in the CA’s database. If there’s no certification, there’s no authentication.

Without certificates, then, complex PKI systems are impossible to administer. The problem is that CAs keep certificates in truststores, which hackers can infiltrate to grab the user/server signature and private key. Plus, unless you or a service provider routinely checks for an expired certificate, you’ll eventually run into accessibility issues. There’s no way to tell how long a key is valid for.

That’s just the start of why PKI security just doesn’t live up to its promise …

The hidden cracks in PKI

PKI for identity encryption has glaring weaknesses. These are becoming more apparent as fresh technology such as Almefy presents an alternative to the public/private key exchange.

This is what you’re risking with a public key infrastructure:

● When you generate a public key, it’s there for anyone to see in your network traffic. Sure, it’s encrypted with a random list of numbers, but it can still be cracked and hacked. Furthermore, encryption keys are generated and stored on a device. If that device is compromised, a hacker can potentially break into hundreds or thousands of user credentials.
● Similarly, if you lose the private key, it’s gone forever. Expensive, complex system overhauls will have to take place, blocking the old key and matching public keys with a new master identifier.
● The IoT complicates matters even further. Thousands of keys are exchanged between devices at any given time. This represents a much broader risk surface for your organization.

Do you need PKIs for two-factor authentication?

Until very recently, you did. We’re talking about passwords, after all. They’re a pillar of traditional two-factor authentication.

2FA still relies on user accounts and passwords to access them. Typically, you’re just adding another layer of protection with an OTP sent by tools such as Microsoft Authenticator or Google Authenticator. But everything else remains at risk for the first factor: the public key floating in your network traffic, the private key in your hands, and the certificates susceptible to hacking or expiration.

At the same time, an OTP isn’t bulletproof either. Advanced hackers with the right skills and workarounds can trick users into giving up their OTPs, granting access to your platform. This is mainly accomplished with a proxy page, which copies your digital portal. The victim goes through the whole authentication process including the OTP — enough information for hackers to utilize a reverse proxy, taking control of
the user session.

Too many organizations assume that 2FA is the safest way to limit access and guard data. Yet, the truth is that anything with a password is begging to be compromised. Whenever PKIs and OTPs are involved, there’s trouble on the horizon.

So, can 2FA be improved? You bet. We’ve created the solution ourselves.

Our certificate-free alternative

Almefy gets rid of passwords and PKIs entirely. You don’t require them to securely confirm someone is making a valid log-in attempt.

Instead, our software uses identity-based encryption (IBE). It streamlines two-factor log-ins with a QR code and a registered device. That’s all you need.

Once a user registers with Almefy, they enter an identifier like a phone number or email address. Then when they try to access your platform, application or data bank, the QR code appears on screen. They scan it with a mobile camera. Almefy confirms the request and grants the user entry. No passwords. No saved credentials. You won’t even touch the keyboard.

Although Almefy does generate public keys, they self-expire when the user connects to the server. Our technology doesn’t rely on digital certificates or client/server time syncs to validate access. You’ll swerve the risks of certificate management, along with any third parties. Machine identities become the lynchpin for your security. It’s a revolutionary method for encryption and trust amongst the tools you depend on.

Can we show you what Almefy is capable of? It’s the single key to every door. Try the Almefy app and leave the public key infrastructure behind, where it belongs.