Unlock with SSO: under the hood

Since then, we’ve spoken with many of you who are eager for more of the technical details – and we’re happy to oblige! We love a good deep dive, so let’s talk about some of the thinking behind our approach.

In this article, we’ll pull back the curtain a bit on the technical foundations of Unlock with SSO. We’ll touch on why it’s a tricky problem and how we engineered a solution that lives up to the 1Password promise – including how we ensured that no one but you can access the data in your vaults. Finally, we’ll share some notes on what Unlock with SSO means for the security of your 1Password account, and what the future holds.

SSO and a decryption problem

Most web services “just” need to solve authentication and authorization problems – ie. determining whether a user is who they say they are, and whether they should have access to a resource. For these kinds of services, SSO is an ideal solution for organizations: It provides centralized management of what users can access, and allows enforcement of strong authentication, policy, and auditability.

1Password also needs to solve authentication and authorization problems - but the password you use for your 1Password account today also needs to decrypt your passwords. Your account password makes sure only you can do that. When we designed 1Password, we had to account for the possibility that some day our servers could be compromised. With the new ability to unlock with SSO, we wanted to stay true to our decryption promise. Our SSO implementation makes sure that neither 1Password nor the identity provider could gain access to your passwords.

The challenge is that traditional single-sign on is not made to solve this decryption problem. Popular protocols used for signing in with SSO – OAuth, OIDC, SAML – don’t provide a way for the user to end up with a decryption key only they know.

The 1Password solution and how it works

To stay true to our promise, we needed something on top of traditional SSO. When using an SSO-enabled account, decryption is handled by the device on which 1Password is already installed, using a key – called the device key – that is unique to each device. The device key is stored on users’ devices, and only on users’ devices.

Signing in

The device key is what helps complete the process of signing in to 1Password with SSO, and it works differently than our traditional unlock. In today’s password and Secret Key accounts, your account password and Secret Key fill two important (but distinct) security roles. Your account password protects your data on your devices, whereas your Secret Key (in addition to your password) protects data on our servers. In other words, your devices are responsible for memorizing a strong cryptographic key (your Secret Key), while your password ensures that only you can unlock 1Password on your device.

With SSO-enabled accounts, your device remains responsible for providing a strong cryptographic key (its device key), while your identity provider becomes responsible for making sure that 1Password can only be unlocked by you. How the device key is stored depends on the type of device you are using. The table on this support page details how this differs between platforms.

Your account password and Secret Key fill two important (but distinct) security roles.

With password and Secret Key accounts, your password and Secret Key are combined to derive two separate keys: an authentication key, and an encryption key (we call this pair of keys your credential bundle). Both your password and Secret Key are required to be present to create this bundle, which allows you to sign in to 1Password, and then to decrypt your data.

Using an SSO-enabled account, your credential bundle is instead made from two randomly generated keys, and encrypted by your device key. The encrypted credential bundle is then stored on 1Password’s servers. Since the device key is only stored on your device, only your devices can decrypt this credential bundle. 1Password’s servers will only “release” this encrypted credential bundle to your devices if you can sign in with your identity provider.

Quickly unlocking with biometrics

Since the app needs to check with your identity provider every time you unlock 1Password in this setup, by default SSO-enabled accounts can only be used when the app has an active internet connection. However, part of the convenience of 1Password is to have your passwords, secure notes and saved documents available even when connections are spotty. So, to help make secrets still available offline, we’ve leveraged a favorite feature of the 1Password apps: biometric unlock.

Once enabled, 1Password clients can use biometrics to securely store your credential bundle and a re-authentication token on-device.

Administrators can enable biometric unlock for their users in their account settings. When enabled on devices that support it, 1Password clients can use biometrics to securely store your credential bundle and a re-authentication token on-device. Your device-stored credential bundle is then used to unlock 1Password, even while offline, and the re-authentication token is used to re-authenticate with the 1Password server, so it can continue to synchronize vault data when you’re online.

Biometric unlock is supported on macOS using a T2 or Apple Silicon chip, Android and iOS devices with their built-in secure elements, and Windows devices with Windows Hello. (On Windows, the apps don’t use a secure element, but store the re-authentication token in protected memory while the 1Password app is running.)

A reauthentication token is only ever issued in response to a successful authentication, and when issued, it’s protected by session encryption to guard its long-term secrecy in the event of a TLS confidentiality failure, just like your other 1Password account data.

When a re-authentication token is used, it is protected by TLS. Because of this, after a re-authentication token is used, the 1Password server considers it ‘spent’ and it cannot be used again. As a result, a new re-authentication token is requested every time a biometric unlock is performed. 1Password apps also use a re-authentication token, and fetch a new re-authentication token while they are unlocked to ensure 1Password stays unlocked as long as it is permitted.

When an admin turns on biometric unlock, they delegate the responsibility of authenticating a user, temporarily, to a user’s device, in place of the identity provider.

Trusted devices

When you register with an account using SSO, the device you use to sign up becomes your first Trusted Device. When a device is trusted it means that this device has a device key which has encrypted your credential bundle (and therefore is capable of signing you in). You trusted it to log in.

A critical challenge to overcome with Unlock with SSO is setting up additional trusted devices while keeping your credential bundle private. Your first trusted device will generate your credential bundle and then encrypt it with its own device key. But every other device will need to obtain a copy of your credential bundle, so that each device can encrypt this credential bundle with its own device key.

When you first sign in on an additional device using your identity provider, that new device will go through an enrollment process. This enrollment process involves securely transmitting your credential bundle from an existing trusted device which has access to it, to a new device that (currently) cannot access it. This will allow your new device to complete sign-in, and to decrypt your 1Password data independently – becoming a trusted device itself.

When you first sign in on an additional device using your identity provider, that new device will go through an enrollment process.

The first step in this enrollment process is to sign in using your identity provider. This gives 1Password’s servers reasonable confidence that you are trying to sign in on a new device. Once this happens, 1Password’s servers then send a notification to all your currently trusted devices, asking you to approve the new sign-in on one of them.

Once you receive this notification on a trusted device, you can approve or deny the sign-in. To approve the sign-in, your trusted device will generate a random code, which you’ll enter on the new device. When you enter this code, your devices will use it to authenticate an end-to-end encrypted handshake (more detail to follow), which will allow your trusted device to securely transmit your credential bundle to the new device. When your new device receives your credential bundle, it will use it to sign in to your 1Password account and register itself as a new trusted device, encrypting the credential bundle with its own device key.

End-to-end encryption when enrolling a new device

Background and goals

We wanted to make new device enrollment easy for users to accomplish. Asking them to manually enter a 32-byte key might be one way of securing this, but it’s not very easy to use. Entering a relatively short confirmation code, on the other hand, is easy.

However, this presents a tricky security challenge. To secure communications between both your devices, we couldn’t just encrypt your sensitive data with a short code; this would not be secure. Instead, we needed the confirmation code to confirm a channel was trustworthy, without using the code to directly encrypt anything.

End-to-end encryption between your devices during enrollment is critically important to keep our promise that only your devices are capable of decrypting your credential bundle. Because 1Password’s servers are relied on to facilitate this enrollment, there are several important considerations to get right, and we’ve designed this exchange to be secure even if someone stores or actively tampers with the communications between your devices. Specifically, this exchange adheres to a security property known as Perfect Forward Secrecy.

This exchange adheres to a security property known as Perfect Forward Secrecy.

The communications between your devices are authenticated by a randomly generated code, but not encrypted by this code. This is important to mitigate against brute-force attacks on the code itself, ensuring that nobody in a network position, including the 1Password server, can decrypt your credential bundle. By instead using this code to authenticate the exchange, your devices can use strong ephemeral keys, and can enforce that only one attempt can be made at providing the correct code.

The key is in the PAKE

To secure this exchange with a code, we use a symmetric Password Authenticated Key Exchange (PAKE) called CPace. You may already be familiar with the idea of using a PAKE if you’ve ever heard us talk about SRP, or Secure Remote Password. SRP is an asymmetric PAKE, which means only one party in the exchange – you – has the password. CPace is a symmetric PAKE, which means both participants share a common secret. In our new device enrollment process, the randomly generated code is this shared common secret, and is known by both devices after you enter it on a new device. CPace was purpose-built to facilitate creating a secure channel between two devices, and also comes with a security proof for perfect forward secrecy – so you don’t just have to take our word for it being secure!

At a protocol level, CPace neatly neutralizes the possibility of brute-force attacks on the shared code by splitting its handshake into two distinct stages.

How we use CPace in enrollment

At the first stage of the handshake, both devices use a randomly generated key and the shared code to generate a “commitment” value. Because each side has mixed in a randomly generated key, this commitment cannot be used to guess the code itself (since there are two unknowns).

Both devices then use their key and the shared code to derive a new shared key. If both devices had the same code to begin with, they’ll arrive at the same shared key, but if they didn’t (or their commitment values were tampered with) then they’ll end up with different keys. Because this key is bound to the shared code, the handshake state, and each side’s randomly generated key, it is not possible to guess the shared code again without performing an entirely new exchange.

Both devices then move on to the second stage of CPace: key confirmation. Each side will use its version of the shared key to authenticate a unique message which identifies it to the other side. The devices will emit different confirmation messages to each other, but both devices (if they have the same key) are capable of verifying the message from the other side. If these authentication messages are correct, each device knows that the other used the correct code, but if not then the device will know they should abort.

Both devices (if they have the same key) are capable of verifying the message from the other side.

Once this authentication stage has completed successfully, the exchange is complete and the devices can communicate in a way that is end-to-end encrypted. The final step to complete enrollment is for the existing trusted device to use this shared key to encrypt your credential bundle to send it to your new device. Once your new device receives it, it will be able to sign in, decrypt your 1Password data, then register itself as a trusted device by generating its own device key.

Manageability and risks

Offering an option to integrate with SSO providers has been a longstanding request for us for good reason. Single sign-on plays a central role in enterprise security by offering enforcement of strong authentication, centralized management of users joining and leaving, and fine-grained auditability of sign-in events.

The security of any SSO system comes with tradeoffs, however. Once someone can produce a proof authorization – for example, an OAuth authorization token or a SAML assertion – a resource server will let you access your data. The information to get that authorization is commonly stored on end user devices. Unlock with SSO in 1Password doesn’t solve that problem: in scenarios where an attacker gets access to a user’s computer (or a copy of the data on that computer), they can steal the device key and any SSO sessions a user has from their computer, and proceed to sign in and gain access to their SSO-enabled 1Password account. The incident report of the recent breach at CircleCI demonstrates that stealing local credentials is a real concern, even when strong authentication mechanisms are enforced.

Protecting sign-ins to SSO services comes down to having a strong device security program and security monitoring.

For readers familiar with SSO, this may be an obvious limitation and a risk that is mitigated by other measures. Moreover, many will assert that authorizations in SSO are fundamental, and this is how SSO products should work. For our product this is new territory however, and this took a tremendous amount of consideration for us. We considered the abilities of identity providers to detect and prevent this misuse, but can’t vouch for the abilities of Okta or other identity providers in this regard. On devices that support storing decryption keys in hardware – macOS, iOS and Android – the 1Password apps for these platforms protect the device key in hardware when possible, making it much more difficult to extract from a device. Fundamentally, protecting sign-ins to SSO services comes down to having a strong device security program and security monitoring.

There are other security tradeoffs that prospective adopters of Unlock with SSO should take into consideration, such as educating users about sharing device setup codes and considering the availability of the identity provider for access to passwords. Read more in our support article about Unlock with SSO security.

Where to next?

In this deep dive, you might have noticed that we made few references directly to Okta. Because SSO providers (including Okta) tend to build on open standards, we have built Unlock with Okta in a way that’s extensible in the future. Unlock with Okta will be available to all 1Password Business customers soon. Afterwards, we’ll be focused on Azure, followed by other identity providers like Duo, OneLogin, and more. Our initial flurry of releases will focus on OIDC, but SAML is also on our roadmap.

Another thing that might stand out to the keen-eyed: with the credential bundle, does Unlock with SSO still use Secure Remote Password? The answer is yes. For the moment, it was more straightforward for us to leverage our existing unlock methods – including Secure Remote Password. This allowed us to build Unlock with SSO without needing to reconsider assumptions about how authorization with the 1Password service works. Nonetheless, we are using Secure Remote Password when there are no traditional passwords in play anymore. If you use a password with your identity provider, that’s between the identity provider and you. In the future, we might be interested in using a bespoke system for the 1Password device to talk to a 1Password server when authenticated through SSO.

As we expand to more customers with different security requirements, we are also looking to introduce ways to gain even more fine-grained control over how users can sign in to SSO, including helping to enforce protection on the device key.

Usable security for the enterprise

We built Unlock with SSO in a way that fulfills the 1Password promise: Your secrets remain yours, and yours alone. The device key keeps everything local to your device, and through our use of CPace, adding new devices is quick, easy, and secure.

We don’t see a contradiction between convenience and security. Ease of use is a security feature, and that holds true for Unlock with SSO. We hope that it helps more organizations enjoy the benefits of an enterprise password manager by making strong security simple – even if the underlying infrastructure is, as we’ve seen, a bit more involved. 😉

If you’d like to read more details about how SSO sign-in works, check out the SSO content in our Security Design whitepaper.

Rick van Galen & Aidan Woods