How to Access Infrastructure Without Usernames and Passwords

Passwords are bad for you

A password is a secret, and a secret can be lost, stolen or traded on dark web marketplaces. Most engineers know this, that’s why every SSH tutorial begins with the instructions for disabling passwords and enabling private/public key pairs. But a private key is just another form of a secret.

In this article, I will try to explain why all forms of secrets are bad for you.

Information security experts will tell you that most successful infrastructure attacks that lead to breaches and data exfiltration often follow the same “error+pivot” pattern:

• Human error is exploited. This gives an attacker an initial stronghold, it could be a compromised box on the edge or a programmer’s laptop.
• Pivot. An attacker attempts to infiltrate adjacent infrastructure in order to get access to as many things as possible. Sometimes this is called “expanding the blast radius”.

If you pay attention to the security industry, you know that most security solutions focus on scanning for errors such as erroneous configuration, code vulnerabilities, etc. or on trying to minimize the blast radius.

Now it’s easy see why passwords, private keys, API keys, and all other forms of secrets are fundamentally dangerous:

Secrets increase the probability of human error.

Mind you, us humans have the best intentions most of the time. But we also have bad habits, we get tired, we like to cut corners and some are bad apples. Reliance on secrets as authentication credentials allows the following to occur:

• Secrets can be shared with other people
• Secrets can be lost or accidentally leaked
• Secrets can be stolen
• Secrets can be sold on the dark web

Encrypting does not help much, as it only shifts the attack focus from one secret to another — the decryption key.

Your organization hires the best talent, practices rigorous security hygiene, uses encrypted vaults to store secrets, etc. Congratulations, the probability of any of those happening is probably low. But as your team and your infrastructure grow, the secrets multiply and the probability of a human error happening increases as well. In other words:

Secrets do not scale.

The industry’s response has been the switch to identity-based access.

What is an identity?

The central idea behind identity is consolidation. Instead of configuring every computer system (protected resource) with its own user accounts and credentials, a single centralized user database is used. User credentials and associated metadata such as roles are now stored in one place vs many. This greatly reduces the number of secrets scattered across an organization. Every account in this database is called an identity and these databases themselves are identity management platforms (IDM).

IDMs not only enhance security but also offer the convenience of a single sign-on (SSO). When a user tries to access a protected resource, she is forwarded to an IDM provider, where she authenticates with a password and multi-factor authentication (MFA). If the login process succeeds, what happens next is an identity transfer, when an IDM sends her account information to a protected resource via protocols such as SAML or OIDC.

Switching to identity-based access with SSO is a good thing, but in the continuous arms race of attackers and defenders this is no longer enough:

• Identities stored in an IDM are themselves just data, and are vulnerable to theft. IDMs themselves are web applications that can be hacked, because all applications are vulnerable to human errors.
• Access to IDMs themselves are protected by — you guessed it! — a password hopefully hardened by MFA.
• The identity transfer from an IDM to a protected resource during SSO often relies on browser cookies, another form of a soft secret that can be stolen or sold.

What is the industry response to this?

Passwordless

The new kid on the buzzword block is “passwordless”. But perhaps “physical identity” could be a better term. The idea is to move away from storing identity only as a password-protected electronic record, to relying on physical attributes of humans and machines that aren’t electronic, and therefore cannot be stolen, lost, shared or traded. Let’s use an example.

Consider a DevOps engineer Lisa who needs access to infrastructure such as SSH servers, Grafana dashboards, MongoDB databases, AWS API or Kubernetes clusters.

Traditionally, Lisa would have an account in all of these systems. But if she works in a modern tech company, perhaps they have already integrated SSO into all layers of their tech stack. She clicks on the “Login with SSO” button, uses her IDM password and MFA. Now her browser has a cookie which allows her to access protected resources.

There are two secrets that are vulnerable to exploitation here: her IDM password and the cookie. Can we get rid of both? Yes, we can, by switching to a passwordless access. Here’s how it works:

To access a protected resource, Lisa clicks the SSO button and, instead of presenting a password, she must have two physical objects that define her physical identity:

• Her fingerprint or/and facial recognition, a human identity.
• A hardware trusted platform module (TPM), a machine identity. All Apple devices have one. Other systems can have this capability via something like YubiKey Bio.
• A username is not required anymore.

This allows us to get rid of the IDM password. But how about transferring Lisa's identity to a protected resource without a cookie? A much better technology for this is a certificate. All modern infrastructure protocols support certificates. A certificate can be tied to a TPM of Lisa’s machine. It also may contain metadata, such as Lisa’s role, which can be used to determine what actions she’s allowed to perform on a resource. A certificate also can expire after a few hours, or even seconds, or be revoked on demand. This makes certificates less vulnerable to loss or theft.

Who issues certificates? They are created by a certificate authority (CA). In such a system, the total number of secrets shrinks to just one: the CA itself. Here’s how before and after picture looks like:

Why is passwordless better?

• There are no “soft” secrets of any kind that can be stolen, lost, sold, shared, etc. The client private key resides in a TPM and is not accessible.
• It is less prone to human error. You need to be Lisa, and you must own a TPM-equipped device registered with the CA.
• The CA becomes the only remaining secret in an organization which itself can be stored on an HSM.
• This access architecture is scalable. No matter how many DevOps engineers an organization will have, the number of infrastructure secrets will remain the same: just one.

We are a cyber security company. Our most technically sophisticated customers, usually SaaS or FinTech companies, have a few things in common: they’re scaling and they take security seriously. Based on their requests, we’ve built passwordless infrastructure access and open-sourced it.

Trying passwordless

Today we are happy to announce Teleport 10. It includes the early technology preview of passwordless. Everyone can download Teleport and play with it on their own servers. Before we get to the tutorial for setting this up, let’s introduce Teleport to those who haven’t used it yet:

Teleport is an open source, multi-protocol access proxy with an integrated certificate authority. The latest version allows certificates to be issued based entirely on the physical identity of a user. Teleport supports all common infrastructure protocols:

• Linux servers via SSH and Windows hosts via RDP
• Kubernetes API, and other HTTPs endpoints behind NAT/firewalls.
• MySQL, PostgreSQL, MongoDB, Elasticsearch and other databases.
• Infrastructure management web apps like AWS Management Console, Jenkins, GitLab, etc.

Teleport is a single binary which can run as a traditional Linux daemon or be deployed into a Kubernetes cluster via the CRD mechanism. It scales from a single Raspberry Pi to thousands of servers, and is used for accessing production infra at Snowflake, NASDAQ, Square, Vonage and others.

Passwordless Demo

For those who don’t have the time, here’s the demo of how passwordless works. We’ll show how to enroll a new identity into the system, and how to login into your infrastructure using nothing but your hardware+biometric credentials:

Teleport is an open source project, and it is being developed in the open. The full changelog of all Teleport releases can be found here, and the list of all 10.0 features and improvements can be seen in this GitHub Release or our in depth blog post for all Teleport 10 features.

Here’s the best way to try the latest release:

• Download Teleport 10
• Follow the Teleport Passwordless tutorial
• Join the Slack channel where Teleport users and developers hang out. User experience is very important to us, so let us know where we can get better!