Tresorit offers maximum confidentiality of your uploaded contents by using end-to-end encrypted technology. Your files are encrypted on the client device before they get uploaded to our servers, and never get decrypted until they reach your client device again. Your encryption keys and passwords are all managed on the client side, and just like your files, they never leave your device in an unencrypted, or otherwise intelligible fashion. Therefore, your content is accessible to only you and the ones you have explicitly shared it with. Neither Tresorit, nor other third parties have access to your data.
💡 For more information on our security, visit our website. You can also read our Terms of Service and Privacy Policy.
Introducing SSO
Tresorit is currently offering Single Sign-On support for Microsoft Azure AD and Okta. This feature allows your subscription members to use their existing company credentials to access their Tresorit account. They no longer need to set up a separate password for Tresorit. Subscription administrators can leverage the central password policies and 2-step verification options offered by their company identity provider.
By the nature of how SSO services work in general, in some configurations, using this feature may affect the confidentiality of your files stored in Tresorit. This document aims to give a short summary about the inner workings of SSO integration in Tresorit and to summarize the consequences you ideally would like to assess before enabling this feature.
Authentication and encryption in Tresorit
Your files stored in Tresorit are encrypted with a complex hierarchy of symmetric and asymmetric encryption keys. Eventually, the master keys to access your content are stored in your so-called user profile. This is an encrypted container stored in Tresorit’s cloud. This scheme maintains the zero-knowledge principle, but also allows you to access your files from different devices.
Pink and blue are standard user profiles, the one with the tie is the admin account
To access your files from a new device, your client application first authenticates itself towards Tresorit’s servers, downloads the encrypted user profile, and then decrypts the user profile locally to obtain the encryption keys for the rest of your contents.
Standard password-based authentication
In the standard setup, the server-side authentication and client-side decryption are both based on your Tresorit account password. The Tresorit client application computes two separate values from your password using a one-way algorithm: one used in authentication, and one for user profile decryption.
One reason for this is convenience: this way you don’t have to remember two separate passwords. The use of one-way algorithm guarantees that even with the knowledge of the derived authentication secret it is impossible to calculate the original password or the decryption key. Because your password never leaves your client device, Tresorit servers never have any knowledge about any decryption keys.
A one-way operation computes two separate values from your password: one used in authentication, and one for user profile decryption.
SSO authentication
If you are using SSO authentication, you won’t have a Tresorit password, so both the server-side authentication and client-side decryption must be based on other components. When signing in to Tresorit via SSO, you’re entering your (company account) password on the SSO provider’s own login screen, the Tresorit application does not have access to it. The SSO provider will return a claim to the client application that proves that you’ve successfully authenticated yourself.
Based on the trust relationship set up when you configure SSO for your Tresorit subscription, Tresorit’s backend will be able to verify the origin of the claim and provide access for your encrypted contents. The Tresorit client application can use the claim to obtain a second secret from the SSO provider that will be used to decrypt the contents on the client side.
Tresorit relies on the SSO provider’s claim to decide on allowing access to the encrypted contents. The user profile is eventually decrypted with a key stored at the SSO provider.
Conclusion
Whether you’re using standard password-based authentication or SSO, as a service provider, Tresorit never receives your password or gets access to any of your encrypted content in any kind of intelligible or decrypted form. All cryptographic operations are done on the client side, maintaining end-to-end encryption and zero knowledge.
By setting up SSO for your Tresorit subscription, you’re trusting your SSO provider to access and store Tresorit user profile encryption data that previously existed only in the memory of your colleagues, in addition to the information for verifying passwords that the SSO provider already does.
For most cases, this is not a new or serious concern, as all other company systems processing sensitive information (email, device access, additional cloud storage, payroll CRM, etc.) already have SSO configured and this risk was already assessed and accepted.
Your choice of the SSO provider also has some implications on the level of security:
- Azure AD and Okta handle “Tresorit login key” slightly differently. In both systems, it is implemented as a profile extension field. In Azure AD, other authorized applications and users may have potential access to profile extensions. Okta is more secure in these regards, keeping this piece of information absolutely private to the users and their administrators only. On the other hand, it displays it on the users' own profile pages and allows editing, which may lead to confusion in some rare cases.
- Tresorit’s own service infrastructure - including the storage of encrypted user content - is built on Microsoft Azure services, which is another consideration when choosing Azure AD as the SSO provider for Tresorit.
Introducing SSO can have several positive effects on the security of your Tresorit subscription, including the benefits of central user management, the ability to enforce password strength policies, or the ability to support other 2-step verification methods. These are general to all cloud-based services with SSO support, and out of scope of this document.
Mitigations
Tresorit provides a couple of controls that you can leverage to minimize exposure of your highly sensitive data:
- Administrative actions requiring Advanced Control (for example, resetting subscription members’ passwords) will still require the subscription administrator’s Tresorit password, even if SSO is enabled for the administrator.
- By using separate policy templates, you have detailed control over who should use SSO and who remains on password-based authentication in your subscription. This way, you can create a circle of employees who manage data of the highest sensitivity with the highest security Tresorit can provide, while providing others with the convenience of SSO.
Still have questions left? Drop us a line