Your roaming profile contains your secret keys to access your private keys to securely access and decrypt the contents of your tresors. This makes the roaming profile one of the most sensitive information in Tresorit, that is why it is protected with your password that never leaves your computer in any unencrypted or reversible form.
When you sign up for an account, a random 256 bit master salt is generated, which will be used along with your password to derive your 256-bit master key using scrypt (RFC 7914) with N = 32 768, r = 8 and p = 1 parameters and a HMAC step using SHA-256 (FIPS-180-4) . Your roaming profile is then encrypted using AES-256-GCM to provide integrity-protection as well before it gets uploaded to the cloud during the registration process.
At the same time another key is also calculated from the output of the scrypt with a HMAC step using SHA-256. This derived authentication key is also sent out to Tresorit servers during registration, where it will be used to authenticate you at the first time you log in (see below).
When you log in to your Tresorit account for the first time on a device (or for example if you have reinstalled your operating system), you have to obtain your roaming profile from Tresorit’s servers. In this case you also do not have your SSL client certificates, so you have to authenticate yourself to our servers using a proprietary challenge-response protocol, based on the authentication salt and authentication key established during the signup process. We use PBKDFv2 and HMAC based challenge-response protocol, something similar to CRAM-MD5 (RFC 2195), but it uses SHA-1 and PBKDFv2 with HMAC with SHA-1 for password derivation as recommended in NIST 800-132.
During the authentication process, the server generates a 160 bit random nonce and sends it back along with the authentication salt as a challenge. The client assembles a response value which contains the authentication salt received from the server, and a newly generated 160 bit client-side temporary salt value. It then calculates your authentication key again from your password and the authentication salt provided by the server and uses it to derive the actual response using the PBKDFv2 algorithm with SHA1 and 1 iteration and sends it back to the server.
As the server is also able to calculate the proper response value using the stored authentication key and the PBKDFv2 algorithm, the authentication process is finished successfully if these two values match.
Please note that your password never leaves your computer, and the Tresorit client application still communicates with the server over SSL/TLS connection, but only in this scenario without client certificate authentication.
In case of successful authentication your encrypted roaming profile gets downloaded and decrypted using your master key, calculated from the password entered during login. In the next step brand new device specific keys are generated. One of these keys will be used for SSL/TLS communication. With the other one we update your roaming profile to make it decryptable with it as well. This allows us not to store your password or your master key on any of your devices. Also, these device keys never leave your computer, and they are stored in an encrypted storage (local profile) even locally, along with your roaming profile.
With a successful login you have acquired your device keys for SSL/TLS communication and roaming profile decryption, and with your decrypted roaming profile you are able to access the contents of your tresors.
For the differences of SSO authentication, please read Technical and privacy considerations when using Tresorit's SSO integration.
When you log in to your account with your roaming profile and device keys available on your computer, we only need to decrypt the local profile. It can be opened with multiple keys, just like your roaming profile, one of them is your password. For normal login a local master key is used, calculated from your password using PBKDFv2 algorithm with SHA-256 (FIPS-180-4) with 100000 iterations. This key is different from the master key used for your roaming profile encryption.
When you enable the auto-login feature, the local profile (where your device specific keys are stored) can be also decrypted using an autologin key. This key is stored using platform specific local encryption services provided by the operating system.
As your password (to be more precise, the master key and the authentication key, both irreversibly derived from your actual password) is used both for encrypting your roaming profile and authenticating you to Tresorit’s servers, it gets tricky when you decide to change your password.
First, the client initiates the same challenge-response protocol as in the first-time login process using your old password. Then a new master salt and authentication salt are generated and the new master key and authentication key are calculated from your new password using the process described above for sign up.
Your roaming profile gets re-encrypted locally using the new master key, then the client sends the newly encrypted roaming profile and the new authentication salt and key along with the response, which concludes the password change process.
Please note that your old password is also required for the password change, and not only the Tresorit client application but also the Tresorit servers require it to prevent malevolent people from changing your password in the unfortunate case when you leave your device unattended, unlocked and with Tresorit client logged in. Also note that since the password change process involves the complete re-encryption of your roaming profile, the password recovery is theoretically impossible. If you ever forget your password, you will never be able to access your Tresorit account again! All you can do is to delete and re-register your account.
Your local profile contains all the information required to locally map your tresors to folders on your device. Because of this, the local profile is only relevant for a specific device of yours and unlike your roaming profile, it never gets uploaded to the cloud. However, the local profile is also encrypted and integrity-protected using AES-256-GCM as the roaming profile.
Technical background of password recovery
In case you’ve forgotten your password, you can change it by requesting a one-time authentication code via email. This method requires a working Tresorit desktop client application that automatically signs you in.
Your password is indispensable for accessing your tresors, but it’s never used directly. There are two pieces of information that are irreversibly derived from your password using scrypt algorithm. The authentication key is used to prove your identity to our servers when downloading your encrypted roaming profile that stores access keys to all of your data. The master key is used to encrypt/decrypt your roaming profile. Normally both are required to change your password.
Tresorit has no access to your password, it is never stored or sent anywhere by Tresorit. The password code feature will not recover your actual password, but it helps you create a new password securely.
As you’ve been automatically signed in to the client application, a device specific private key is already available without knowing the password: the automatic sign-in works by decrypting your roaming profile directly with this private key stored on your device. This device specific private key never leaves your device, it is stored locally and protected using secure platform specific methods.
However, it’s still required to prove your identity to our servers. Because the password is unknown in case of automatic sign-in, there’s no way to calculate the authentication key that would normally be used in the challenge-response protocol during authentication. So instead of this, we send a randomly generated, one-time authentication code to the email address associated with your Tresorit account. Similarly to two-factor authentication, we assume that if you are able to obtain the authentication code, it proves that you can access your email account and thus you are in control of the associated Tresorit account.
You will be then able to use this code to initiate the password change, which takes place as usual: a new pair of master and authentication keys are derived from the new password you have entered. Your roaming profile is re-encrypted with the new master key and then uploaded to the cloud. The authentication key is updated as well during the process.
Your devices use different keys to access your encrypted profile. These are not changed during a password change, their cryptographic access and active sessions will not be revoked.
🏆 Pro tip: Need to sign out of other devices too? This is how you unlink a device from your account.
In case of Single Sign-On, your password is not managed by Tresorit, so please contact your administrator for further help.
How your password is managed in Tresorit
💡 Here’s what you can do in case you forgot your password.
Password security is crucial in Tresorit. In order to hide your password from anybody - even from us at Tresorit - we apply the following principles:
For parameters, we use N = 32 768, r = 8 and p = 1.
Scrypt needs big memory in order to avoid GPU cracking (unlike ex. PBKDFv2)
Because of this any UTF8 character can be used in your password, and password length (theoretically) is not limited.
For autologin, new certificates are generated and their private keys are stored only on your computer. One of them is used to authenticate to our servers as a client certificate, another can be used to decrypt your profile. These private keys never leave your computer.
Your encrypted profile contains your private keys used for sharing tresors with others.
By default, we are using SSL Client certificates to authenticate you when you log in to our servers.
The first time you sign in, you need to download your encrypted profile without client certificate authentication. To authenticate, we use a challenge-response protocol, based on a key derived with scrypt with the above described set up. Only in this scenario, the client communicates with the server through SSL without client authentication. We planned to use SRP (RFC 2945) for this, but because implementation problems of TLS-SRP (RFC 5054) we use an application layer challenge-response protocol.
Still have questions left? Drop us a line