Why Developers Need Passwordless
Over the years, we’ve seen a range of attacks on systems due to passwords. Passwords are leaked, reused or phished — the vulnerable entry point into the system.
The solution: Get rid of passwords.
Replacing passwords is often referred to as passwordless, but this is a confusing term as it doesn’t describe what’s replacing it. At the core, passwordless is an authentication method that combines proof of identity (biometrics / Touch ID) and proof of presence (attestation for Secure Enclave on Mac). These two things are all wrapped up in modern web technologies such as Web Authentication (WebAuthn) to make things simple and provide a smooth user experience for users. For example, when you log into your iPhone with Face ID, it’s passwordless; you don’t think about it.
Along with user passwords, there are other password-like credentials scattered in your infrastructure. These are sometimes explicitly called passwords, such as a username and password for a MySQL server, but can also be in the form of long-lived Kubernetes configs that have a very long secret that’s just a password. It could also be a SSH config, used for CI/CD servers to communicate with other machines. We’ll dive into machine-to-machine communication and authentication later in this post.
Problems in Dev Paradise
Over the past few years, developers have been a target of multiple attacks, as most developers require access to staging, build or production environments. With access to sensitive systems, they are hot targets for hackers or even nation-state attacks. The SolarWinds hack showed “phenomenal tradecraft” — once the attacker got a foothold into the system, a backdoor was placed in the build system, then finally deployed to customers.
Other companies such as Twilio and Cisco have come under attack with sophisticated attacks that can even bypass single sign-on (SSO) and multifactor authentication (MFA). Cisco recently observed an advanced bypass of MFA via voice phishing or “vishing.” These incidents highlight that even SSO and MFA might not be strong enough to protect against the most persistent attacks.
Developers’ Dirty Secrets
As part of developers’ day-to-day work, they encounter many secrets. These can range from API keys for services to AWS credentials and kubeconfigs. There are two problems with most of these secrets:
- Most are long-lived credentials.
- They are stored on disk.
Long-lived credentials can pose many risks. For example, a developer might have a Twilio API key that sends SMS, but is this the same key as production? Does this API key get rotated when someone leaves the company? Having long-lived credentials opens up the possibility of lateral movement and possible privilege escalation. Two open-source solutions for secret management are Blackbox and sops. These tools encrypt the secrets, meaning that even if they do get leaked, attackers won’t be able to use them.
Using short-lived and temporary credentials are great for protecting developer accounts. AWS users can use temporary security credentials in IAM in combination with AWS SSO and profiles, aws sso login --profile, to retrieve short-lived credentials. If a machine were compromised, there would be a limited window in which an attacker could actually use a secret. Another interesting open source project, aws-vault, helps solve this problem in development environments.
Lastly, it’s important to use a dedicated service account for machine-to-machine communication. For example, a CI/CD service should have its own service account with limited permissions and credentials. It’s worth evaluating whether you can remove secrets altogether, such as using OIDC for GitHub Workflows to eliminate the need to store long-lived secrets. For other systems, it’s worth investigating open source Teleport Machine ID as a system that will constantly obtain short-lived certificates for access to servers, Kubernetes and databases.
How Does Passwordless Work?
The foundations of passwordless are built on a few standard web standards. For a deep dive, I highly recommend this post, “How Passwordless Works,” for an in-depth review of how both WebAuthn works as well as passwordless. An interesting detail that makes passwordless secure is the fact that verification of identity, either via biometrics or a personal identification number (PIN), never leaves the user’s device. This makes remote phishing attempts impossible, as the attacker would need access to the device.
What’s Unique about Developers?
It goes without saying, developers are power users of their work machines. They are often switching between integrated development environments (IDEs) and terminals to get their job done. They use command-line tools rather than browser-based apps, and these CLI tools often require some form of authentication.
This is where passwordless can get tricky. WebAuthn was primarily designed for browsers, and some security features such as attestation aren’t fully implemented. For example, Chrome relies on self-attestation for Touch ID, since it can’t securely employ a different format.
The next problem is being able to support passwordless authentication methods in the CLI. While developing the open source tsh client, the binary needed to be packaged with the correct provisions profile to be able to work. For other open source developers, this means an Apple Developer account is required to build a CLI that’s compatible with Touch ID.
Why Developers Need Passwordless
This post has outlined some of the risks associated with passwords and points us to a future in which passwords will become a thing of the past. By upgrading to passwordless authentication methods, the risk of attacks is greatly reduced. Teleport is one of the first developer-focused tools to bring passwordless to the terminal without the need for a username or password.
Call to Action for Passwordless for Developer
Audit your developers and systems: To better understand your current security posture, it’s worth identifying all the different tools and authentication methods used for developers and developer-related services. If using a centralized password manager, it might be worth investigating when the password was last rotated and exploring other options.
Upgrade U2F to WebAuth: If you’re working on a product that provides authentication, start by upgrading your older U2F and 2nd factor to WebAuth; there are multiple libraries available to make this easier:
Invest in hardware tokens: Start by buying your team hardware tokens, either YubiKeys, Google Titans or SoloKeys
Upgrade machine-to-machine communication to passwordless: Investigate ways in which you can remove passwords from infrastructure services. For example, if you’re currently using Postgres username and password, consider upgrading to using TLS to connect to your MySQL, then use certificates instead of passwords.
The Future of Passwordless with Passkeys
Apple, Google and Microsoft have been collaborating on making the user experience of passwordless better for the general population. Currently, users need to register and enroll each device they have. For example, a Touch ID registration made on your MacBook won’t carry over to your iPhone.
Passkeys is the solution to this problem, a FIDO2 improvement that will let users easily and securely access passwordless systems across devices and operating systems. The FIDO2 Authentication standards are based on public key cryptography for authentication that is more secure than passwords and SMS one-time passwords. FIDO2 Authentication enables password-only logins to be replaced with secure and fast login experiences across websites and apps.