My 1FA is Probably Better than Your MFA

Multi-factor authentication (MFA) is required and demanded by everyone from regulators and insurance providers to enterprise customers.

What is MFA you might ask? Let me provide a simple review.

MFA means that at least two "factors of authentication" are employed in accessing privileged resources. Think logging onto some internet service, like email, and needing more than just a login and password. Passwords just aren't enough, and that’s not vaguely debatable.

There are traditionally three factors of authentication:

• what you know, such as a password or (some) mother's maiden name

• what you have like a digital key, or in real life, a door key

• what you are, which is often some form of biometrics like fingerprint or an iris scan

But (as usual), let me be a bit contrarian. There is one single-factor authentication that I trust more than any service provider's MFA solution.

Sure, one is usually less than two or three, but in this particular case, I'd disagree.

That tool I trust most is OpenSSH, secure shell, an open-source implementation of SSH.

You can make SSH an MFA solution, but that would distract from my point.

Most people in technology use SSH. It remains the most common tool for managing remote hardware and services. It was brought to the masses by some OpenBSD developers in 1999.

There's a useful overview of OpenSSH history here.

For a funny piece of that history, one of those OpenBSD developers was Dug Song, a founder of Duo, the well-known provider of MFA solutions.

Before SSH, we would use tools like telnet to manage servers remotely. But it entirely lacked security. It was completely unencrypted communications with sensitive network hardware across the hall or the globe, but it was also the accepted norm.

On the other hand, OpenSSH's security track record is strong. Spend some time on security lists, and you'll hear software like "Jenkins" and "Kubernetes" mentioned so frequently that you wonder if it's to drive the SEO. But OpenSSH mentions are a rarity.

The standard method of using SSH is to generate a public and private key. The public key resides on the remote server or service accessed, while the private key is maintained securely on a (more) trusted local system. This is what is meant by public-key cryptography.

Remember "trust" is always relative. I don't maintain absolute trust in myself with the passwords that reside in my head, since someone could extract them with some rubber-hose cryptanalysis.

The simplest way to think about it is that a public key is like a door lock, and the private key is like a physical key. Anyone might have access to that door lock, but the security rests with protecting that physical jangly thing in your pocket.

If you lose that physical key, say to your home or a file cabinet, you may realize this is a security incident, and you should replace both the lock and the accompanying key. Similarly, if you lose your SSH private key, remove that public SSH key from any device or service you accessed with that key. Protecting that private SSH key with a password helps to mitigate its loss. Of course then the only wall between an adversary and the devices and services is that SSH passwd.

The same goes for any private key in a public-key cryptography scenario, including PGP keys.

SSH is something many of us have used daily for decades. Two of three three co-founders of ClearOPS are long-time contributors and users of open-source BSD operating systems, including OpenBSD which maintains OpenSSH.

So when it comes to authenticating to remote systems, give me OpenSSH over anything.

The point of this piece isn't to insult any of the big MFA providers out there. It's just hard to ignore the complexity of their sprawling systems and footprints hidden from the MFA users. Most importantly, we are forced to trust a whole host of abstracted providers in the process: a cell phone and its carrier, the software on that phone or a desktop, the actual service being accessed, not to mention the MFA provider itself.

The true irony is that OpenSSH isn't necessarily considered MFA by cyber insurance carriers. Sure, SSH can be setup wrong, with only password authentication and no public/private keypairs, but it's become quite clear that MFA with the big providers also enable users to do things wrong. Just check out #PassBleed on Twitter.

OpenSSH is not a complex system of providers and millions of lines of software code wrapped up in patents in some corporate vault. Rather, it's a tightly run and heavily audited open-source project. Anyone can (and should if capable) review the source code.

Sure, there are MFA providers that open source their client software, but open-source operating systems also contain the server software that can be reviewed.

You don't even need to sign an NDA for access to the source code.

There is one major problem with OpenSSH: it's a massive monoculture. There is one list of users, but the real list is way longer. From GitHub to Amazon Web Services, OpenSSH is everywhere. Therefore one significant vulnerability with OpenSSH means trouble everywhere. There is Mosh, but that's really not enough usage for any strong resilience in the remote access ecosystem.

SSH can be misconfigured, just like any MFA solution. Here are some basics to keep in mind when setting up SSH:

• The version of SSH should be current.

• No root or full-power administrative user should be able to SSH into a system. And for the Unix crowd out there, that includes any user with UID 0.

• Generating ed25519 private and public keys is essential, instead of relying password-only authentication. RSA and DSA haven’t been recommended in very, very long time.

• Outside of disabling "PasswordAuthentication" to force public-key authentication, don't try to do any cutesy editing of the default sshd_config file unless you know what you're doing. A current version should be more than adequate.

Finally, securing that private key is vital. Password protect that private key. And if it's even suspected that it's been compromised in any way, generate a new keypair and replace the old public keys everywhere.

That last point has provoked some battles in my past. One web developer shop that my client retained insisted on sharing one private key among their staff for making web site changes, stored on GitHub. Fortunately, the client and I maintained a strong relationship, and they sort of laughed off the web developer firm.

I was glad the client laughed. I was personally horrified. I wanted to remove their access to everything.

The notion of sharing a private key hosted on "someone else's infrastructure" is a big no-no.

Using any tool wrong creates bad results, and this is particularly true with a trie and trusted secure solution like OpenSSH.

But in the hands of a reasonably intelligent person, I'll take my 1FA with OpenSSH over your MFA any day of the week.

About the author: George is a co-founder and CTO of ClearOPS. By trade, George is a systems administrator out of BSD Unix land, with long-time involvement in privacy-enhancing technologies. By nature, he thrives on creating unorthodox solutions to ordinary problems.

About ClearOPS. Proactive vCISOs use ClearOPS to automate repetitive tasks, accelerating the growth of their business. A vCISO who can serve more clients is better for everyone. Our mission is to bridge the gap between privacy and security. Inquiries: [email protected]