Passkeys in Practice: A Dive into Passkey Implementation in Specific Energy's IIoT Platform
Executive Summary
Passkeys are a new form of passwordless authentication that have gained widespread support across browsers and operating systems and Specific Energy is all in on passkeys! For too long the security community has burdened users and web application developers alike with the hurdles of trying to properly secure a fundamentally flawed authentication mechanism…passwords. Passkeys are more secure and easier to use than password-based authentication. You can access them using things like your phone’s screen lock, Face ID, touch ID, Windows Hello, your password manager, or hardware keys (like a YubiKey).
Some advantages that passkeys have over traditional password-based authentication schemes include:
- High-entropy (a.k.a. randomness) - Private keys (the secret component of passkey credentials) are not susceptible to brute-force attacks.
- No shared secrets - The server does not require the user to share any sensitive key material. Additionally, credentials are unique to each application.
- Phishing resistant - The user cannot be tricked into authenticating with a credential on the wrong application. Additionally, passkeys only work in “secure“ contexts so it lowers the risk of man-in-the-middle-attacks.
- Resistant to replay attacks - A random challenge from the server is only valid for a single authentication attempt which means that valid authentication responses cannot be intercepted and replayed.
- User verification - Specific Energy requires that authenticators perform user verification during authentication (FaceID, TouchID, Windows Hello, Pin, etc.) to prove that in addition to having access to the key material, they also have an inherence or knowledge factor.
- Usernames - You don’t need to remember them if you use a passkey!
We encourage everyone to set up and use passkeys on applications that support them (including Specific Energy of course) for the security lift and to improve your authentication experience. Read our help page for instructions on setting up a passkey on the Specific Energy application.
A brief history of passwords
Passwords have always been the primary authentication method for web applications. The original idea of passwords was that everyone had their password that they remembered and used to log in to various applications. Some short-comings that arose and continue to plague us include…
Low Entropy
The original intent of passwords was that humans are responsible for remembering them. However due to a requirement of passwords to be “strong“ (a rather ambiguous requirement) people are asked to formulate and remember passwords that are difficult for an attacker to guess. Some password security requirements enforce the use of special characters, numbers, etc. which results in people just appending things like “!1“ to the end of their passwords to satisfy different requirements. Specific Energy takes the approach of checking proposed passwords against a database of known weak/compromised passwords (Specific Energy’s Approach to Password Security). The second approach in particular has shown effectiveness in guiding users towards brute-force resistant passwords, however, these methods are imperfect and place the burden of entropy firmly on humans. The best solution for an individual is to use a password manager to generate entirely random passwords. But again, this puts the burden of bothering to configure and use a password manager on people rather than the application.
Password re-use
Since password managers have been on the scene, password re-use across applications has been reduced but is still a major issue. When a web application suffers a data breach, any recovered credentials can be used to compromise user accounts across different applications. An unfortunate sentiment is that this is the user’s fault for not using a password manager to set unique passwords for each application. However, compromise of secondary accounts due to a data breach should be considered the fault of the applications' for not supporting passkeys or enforcing a multi-factor authentication mechanism along with passwords.
Clunky MFA
Passwords as a single authentication mechanism are simply insufficient. This is why we’ve cobbled on additional methods of authentication such us one-time passwords, push notifications, SMS codes, email codes, confirmation links, U2F, etc. However, these additional authentication steps are just plain annoying. Time-based-one-time-passwords (TOTP) is Specific Energy’s chosen form of multi-factor authentication which requires a second mobile app (like Google Authenticator) and can be jarring to have to pull out your phone, find the authenticator app, and type in the code before it disappears!
Phishing 🎣
STOP! Before you enter your credentials…Is the domain you’re on correct (spelled correctly and the exact same domain on which you created your account)? Is the URL prefixed with https://? These are reasonable things to expect users to do before typing in sensitive credentials, right? Only kidding, of course! Luckily using password managers to auto-fill credentials on secure websites that match the origin for which they were created affords a great improvement over requiring a superhuman level of vigilance. However, even the most vigilant users cannot be trusted to not fall victim to well-crafted phishing attacks. Browser extensions malfunction and short of restarting multiple applications, restarting the host machine, and getting auto-fill functionality up and working again, people often fall back to manually entering credentials. Or, users of password managers fail to take the ever-so-subtle hint that a failure to auto-fill credentials on a website means that they’re likely on a fake phishing website and will proceed to enter everything manually. Multi-factor authentication methods, with the exception of a few, are susceptible to the same form of phishing as passwords! A good portion of corporate security education goes towards teaching users how not to get phished when logging into web applications. It’s time we migrate to modern forms of authentication that side-step these issues.
A primer on asymmetric cryptography
Let’s first talk about asymmetric cryptography as it’s the critical ingredient that gives this form of authentication its favorable properties. Although the proliferation of assymetric cryptography in user authentication is relatively new, assymetric cryptography has been around since the late 70s and we rely on it heavily in our day-to-day activities to negotiate secure connections with websites.
Moxie Marlinspike’s - Bob has a safe
The best analogy I’ve heard to describe asymmetric cryptography was by Moxie Marlinspike, who described using a physical safe to send a letter to someone else. In this analogy, Bob wants to receive a letter from Alice with assurance that the letter was not read by any members of the postal service or anyone that would otherwise be able to read and reseal the letter without Bob knowing. Bob obtains a safe with a combination dial, sets a combination, and mails Alice the safe with the door wide open. When Alice receives the safe, she puts her super secret letter to Bob inside, closes the door, and spins the dial. She puts the safe back in the mail to Bob and when it arrives, Bob uses the combination (that only he knows) to open the safe and read the letter.
In this analogy, the unlocked safe represents what’s referred to as a public key and the combination to the safe represents a private key. The clever bit is that Bob doesn’t have to share his private key (the combination) with Alice in order for her to protect sensitive information (her letter) in such a way that only Bob can access that information. Bob can freely send out unlocked safes to whomever he’d like with the same secret combination so that he can securely receive mail.
Now, there are all sorts of imperfections with this analogy - mechanical weaknesses in the safe, a small number of possible combinations, safes are big, heavy, expensive things to be mailing around, etc. However, this concept holds when discussing digital public/private key pairs. The public key can be shared freely with the world and the holder of the private key can read messages that were encrypted with the public key.
Signing
The example above discusses asymmetric cryptography as it pertains to encryption. However, if Alice sends Bob a message that’s signed “Sincerely, Alice“ at the bottom, Bob knows that this message was intended for him, because he successfully decrypted it with his private key, however Bob has no way of knowing whether this letter was from the genuine Alice or from someone pretending to be Alice that simply encrypted a message for Bob using his publicly available public key. The solution for this problem is cryptographic signing!
With encryption, the goal is to allow anyone to encrypt data using a public key that can only be decrypted by the person holding the corresponding private key. However with signing we have the opposite problem. We want to allow anyone to use the public key to verify that a message originated from a holder of a private key. In order to accomplish this, instead of using the public key to perform encryption, cryptographic signing roughly involves encrypting a hash (so that signatures don’t involve operations on arbitrarily sized data) of the original data to form a signature. A rough example of a message sent from Alice to Bob that has properties of secrecy (the message can only be decrypted by Bob), integrity (message tampering in-transit will result in a failure to decrypt), and authenticity (Bob can assert that Alice authored a message by verifying the message’s accompanying signature) is demonstrated below.
Cryptographic signing is at the heart of FIDO2 credentials that we call passkeys. An owner of a passkey can share the public key portion of their credential with a remote server and subsequently prove that they own the private key material without ever exposing the private key to the server.
How passkeys work
Passkey Registration
The goal of passkey registration is to tie a public key to a user account on the Specific Energy platform. This is done in an authenticated context in which the user is prompted to select a passkey provider, generate a unique private/public key pair, and then persist the corresponding public key to the server’s database. A high-level representation of this process is depicted below. Note that the user’s private key never leaves the authenticator’s possession. As a result, the server does not handle sensitive material like it does in a password-based authentication scheme making a data breach less impactful in the context of passkeys.
Attestation
Attestation is the the process of verifying the make/model of an authenticator during the registration process. The primary use case for attestation is to restrict users to a particular authenticator certification level or make & model to comply with security requirements of an organization. It can be quite tricky to implement and applications are not required to support attestation verification to be compliant with the WebAuthn specification. In fact, Yubico, a member of the FIDO Alliance, recommends against supporting attestation in most use cases.
If a service does not have a specific need for attestation information, namely a well defined policy for what to do with it and why, it is not recommended to verify authenticator attestations.
As a result, many applications forgo requesting/validating attestation information. However, we decided to support it in our implementation. Specific Energy does not restrict users to FIDO certified authenticators or any particular make/model of authenticator. We believe that on average this would lower the rate of adoption because very common passkey providers don’t support attestation at all (i.e. iCloud Keychain) and the security lift is too minimal to justify that level of restriction. However, as FIDO2 credentials gain in popularity and we look back on password-based authentication as a relic, we anticipate that some Specific Energy customers will develop policies around authenticator models to fit their unique use-cases. Supporting attestation paves the way for complying with those policies.
A registration process involving attestation looks something like this…
As a result of the process above, we are able to tie a user’s credential (that supplied a valid attestation statement) to an authenticator attestation GUID (AAGUID). During subsequent interactions with the credential, extensive metadata can be obtained from the FIDO metadata service by looking up this AAGUID. Among many other things, this data includes the FIDO certification status of the authenticator and an icon associated with the manufacturer of the authenticator. Examples of FIDO certified credentials (a YubiKey and Windows Hello Hardware Authenticator) as displayed within the Specific Energy application’s passkey management are shown below.
The validation of attestation statements from Windows Hello hardware authenticators presented a unique challenge. Unlike the typical scenario where authenticators offer certificates directly signed by a certificate authority listed in the FIDO metadata service, Microsoft introduces a twist by employing an intermediate certificate authority. The intermediate authority certificate can be obtained from a URL noted in the Authority Information Access extension in the authenticator’s x509 certificate. This intermediate certificate is signed by a root certificate for Microsoft that’s recorded in the data obtained from FIDO’s metadata service.
Notably password managers like 1Password and iCloud Keychain don’t support attestation statements. This is mostly due to the fact these are synced passkeys (though they implement end-to-end-encrypted vaults) rather than being device bound (i.e. key material permanently resides in a TPM). Apple took a different approach to passkeys than Microsoft in this regard. Microsoft, if the user’s machine is configured with a TPM enabled and secure boot, will bind the user’s passkey credentials to the device’s TPM where all interactions with private key material are performed and guarded by Windows Hello authentication. Instead, Apple stores passkey credentials in iCloud Keychain in order to avoid having to set up credentials for each Apple device which is arguably a better user experience. As far as the security ramifications of synced passkeys versus a device bound credential, synced passkeys have an increased risk of exposure due to the possibility of insecure configuration of cloud accounts used to access credentials or weaknesses in the passkey provider’s service. iCloud requires users to have two-factor authentication enabled on their account and if they don’t at the time of passkey registration, they are prompted to set this up.
Passkey Authentication
The goal of passkey authentication for a user is to prove to the server that they have access to a private key that corresponds to a public key that the server has on record for the user. At a high-level this is accomplished with a challenge-response authentication scheme, but let’s dive in to what happens behind the scenes on the Specific Energy application when someone authenticates with a passkey…
Data Structures
The two chunks of data that are signed by an authenticator during authentication are the client data (in JSON format) and the authenticator data (as a minimum array of 37 bytes).
The most significant pieces of the client data are the challenge and the origin values. The challenge is a value generated by the server, only valid for a particular connection, and can only be attempted to be used once. This prevents authentication messages from being susceptible to replay attacks. At the time of writing this, there are only two origins accepted by the Specific Energy authentication server (https://dashboard.specificenergy.com and https://whatif.specificenergy.com). If an authentication message originates from any other origin, it is considered invalid. Additionally, authentication messages originating from https://whatif.specificenergy.com are considered invalid in the context of the Specific Energy Dashboard application and vice versa. In other words, authentication messages are strictly tied to the context in which the authentication process originated! This, along with checking the relying party ID (specificenergy.com) is key to passkeys being phishing resistant.
The authenticator data structure, as described in the WebAuthn specification, is shown below.
The first piece of information in authenticator data is the relying party ID hash. In the case of Specific Energy, this value is sha256("specificenergy.com"). This signifies that https://*.specificenergy.com (all subdomains) are valid origins to interact with passkeys created on the Specific Energy platform. Checking this value confirms that the passkey was created in the right context and the browser did not erroneously send a passkey that was created for a different relying party. Passkey context is further constrained by validating the origin in the client data above. The next piece of data are eight 1-bit flags. Checking bits 0 and 2 confirms that a user is present and verified. These bits are set if the user successfully passed FaceID, TouchID, pin, etc. verification prior to performing the signing operation.
One peculiar value in the authenticator data is the signCount. It’s sole purpose is intended to detect cloned authenticators. The WebAuthn specification indicates that authenticators supporting signature counters should increment this value by “some positive value“ after each successful credential interaction. The server should check that new values are always greater than the counter value it saw previously for the credential. If a new counter value is not greater than a previously observed value, that means that a cloned authenticator exists! As it could have been the clone or the original authenticator that violated this rule (after the clone was used successfully and outpaced the genuine authenticator), this can only be used as indication of an existence of a clone and not which authenticator is a clone. As far as what do it in the case of detecting a cloned authenticator, the WebAuthn specification has this to say…
Relying Parties should address this situation appropriately relative to their individual situations, i.e., their risk tolerance.
Hardware authenticators (i.e. Yubikey, Windows Hello) typically support counter values where synced passkeys, from what I have observed, do not. In the case of authenticators that don’t support signature counters for the sake of cloned authenticator detection, they consistently supply a counter value of 0.
In conclusion
Passkeys are the most significant evolution we’ve seen in the way that we authenticate with web applications. They represent a shift away from putting the burden and blame on users for compromised accounts. After implementing passkeys in our application, attestation and all, we can’t say that it’s as straightforward as a simple password authentication scheme. However, we view this as a small price for a boost in both the security and usability of authentication on the Specific Energy platform.