Security

TLDR

This page outlines the engineering practices we use to protect your data. Our specific Security Policy can be found at aglide.com/security-policy. Simply put, we take every step we can to ensure your data is protected and only accessible by you. Security is at the core of every product and development decision we make. We're building in-line with SOC2-Type2 compliance. We've already engaged with a third party who will help audit this and aim to have our certification by Q2 2025.

Zero Knowledge

Your Aglide data can only be decrypted using a key generated from your password. Your password is never stored, meaning neither an attacker nor us can ever decrypt it.

End-to-end encryption

Sensitive data (e.g., account credentials) are encrypted locally on your machine, with zero-knowelege keys that Aglide can and will never see.

Gov-grade encryption

Personal data encrypted with a user’s personal server-side encryption key. E.g. personal details.

Industry leading hashing

For all users, we enforce industry-leading hashing (Argon2id), with higher than recommended configuration, to store your master password.

How your data is stored.

All personal details, organisation details, and stored account/item details are encrypted using AES-CBC 256-bit encryption. Effectively everything that can be encrypted is encrypted, and it's encrypted with keys that can only be generated by the end user, meaning they are the only one who can access it. Other information such as a user's master password, that never needs to be retrieved but only verified against, is hashed. There are six types of encrypted data in the Aglide database, shown on the right.

Generating keys

The personal, vault and organisation data encryption keys (DEKs) are never stored in plaintext, and are instead always encrypted with a key encryption key (KEK) before storage. For the vault and organisation keys, the KEK is the user’s master encryption key, and for the user’s key itself it is protected by a key generated from a user’s login password. Similarly in order for an admin to access a managed user’s account details, they require a user’s master encryption key. This is stored in their instance encrypted by their own master encryption key.

Personal Server

Personal data encrypted with a user’s personal server-side encryption key. E.g. personal details.

Personal Local

Personal data encrypted with a user’s personal local encryption key. E.g. account credentials or TOTP secrets.

Vault Server

Vault data encrypted with a vault’s server-side encryption key. E.g. vault information.

Vault Local

Personal data encrypted with a user’s personal server-side encryption key. E.g. personal details.

Organisation

Organisation data encrypted with an organisation’s encryption key. E.g. an organisation’s details, or organisation level app details (billing frequency etc).

Administrative

Administrative data encrypted with a server-wide encryption key, stored in our own secrets vault. E.g. a user’s work email, or stripe subscription ID. This less sensitive information is the only information Aglide can read and is kept to a bare minimum.

How your data is accessed.

Your personal encryption keys are protected by a key encryption key generated from your plain text password. Your plain text password, and the key generated from it, are never stored, meaning it is impossible for us (or an attacker) to access your or your organisation’s data. This is known as a zero-knowledge model.

Authorising users

When you set your password, your password is hashed using the best available hashing algorithm (argon2id), using a server-wide secret pepper and a randomly generated salt. Salting the password adds extra flavour… It means if two users stored the same password, they would appear completely differently when stored. Peppering introduces an extra secret making it one step harder for an attacker. We store this hashed password, ready to authorise you against later on.

When you log in, after verifying yourself with email 2FA, we take the salt from your hashed password and repeat the process with the password you just entered. If the two match, you’re in!

Unlocking user storage

When your account is created, 3 randomly generated encryption keys are created - a local encryption key, a server-side encryption key, and a public private key pair. These are used to encrypt all your sensitive data. When stored, these keys encrypted with one of two key encryption keys (KEK) created from your password. This means each time you log in, the KEK can be regenerated from the password you enter with the same method, and used to decrypt your master keys - unlocking all your items.

The server-side KEK (used to encrypt your server-side key) is generated by hashing your password with the hashing algorithm argon2id, a server wide secret pepper and a randomly generated salt which was created on account creation, and stored in your user instance.

The local KEK (used to encrypt your local and private keys) is generated by hashing your password with the hashing algorithm SHA-256, using the accounts email as the salt.

After logging in your server-side encryption key is decrypted then re-encrypted with a session encryption key and stored in a sessions cache. The session encryption key is then encrypted with a server secret key, packaged into a time limited json web token (JWT) and returned to you in a cookie. This cookie is then used to authorise you each time you request something, and decrypt your items wherever needed, until the JWT expires and can no longer be verified. The local encryption key is decrypted and stored in either the page's cache, or, for the desktop app, re-encrypted using Electron's safeStorage then stored on your hard drive. This means it's never accessible to other programs or websites.

The most important part - master passwords

The weak point of this system is the master password itself. An attacker will try to guess passwords over and over until they gain access. To make this as difficult as possible, Aglide rate limits it's end-points, uses a resource-intensive hashing algorithm to slow an down attack (see implemenation), and we lock users out for 24 hours if they incorrectly guess their password 5 times.

However, the best thing you can do, is make sure that your end-users use passwords that would require an unreasonable number of attempts to guess. To help you do this, Aglide insists that master passwords must be 12 or more characters long, contain at least one number, capital letter, and symbol, and are not one of the 10,000,000 most commonly used passwords. Finally, by default, only Aglide admins have passwords (as end-users can access via SSO) - so you only have to rely on your most experienced users.

Implementation.

Hashing and encryption functions are never written by Aglide. Instead they are invoked from reputable libraries, published maintained by large communities of cryptographic experts.

Hashing

Both the salts and peppers used in these hashing steps are generated with a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) and are 128-bit, recommended by the argon2 specs.

Argon2 is the 2015 winner of the password hashing competition and therefore known to be best in class. Argon2id specifically, as recommended by OWASP, is a hybrid variant that balances strong protection against two key different types of attacks. For all users, Argon2 hashing is set to 64 MiB of memory, 3 iterations, and 4 threads (m=65536, t=3, p=4). These settings are used for all users and are not configurable, so cannot be accidentally reduced by one of your employees. These settings are far more resource-intensive than the current recommendations from OWASP, so provide a high level of difficulty for brute force or dictionary attacks. SHA-256 is a highly secure hashing aglorithm used by many industry leaders, and is implemented using the Web Crypto API.

Hashing functions are invoked from libaraies following the published Argon2 reference implementation.

Encryption

AES is trusted by the US government, and when correctly implemented, and with a strong enough key, it is effectively unbreakable. It’s also considered quantum-proof.

Each encryption key is 256-bit, generated with a Cryptographically Secure Pseudorandom Number Generator (CSPRNG). The initialisation vector used (iv) is 128-bit generated through CSPRNG.

Cryptographic are invoked from reputable libraries.

Accessing Aglide.

When accessing or contacting Aglide, it is important to verify that it is really us. To make that as easy as possible, there are very few offical Aglide outlets. All online clients are hosted on aglide.com and subdomains of it, and there are only three places you should ever enter your Aglide master password, any 2FA codes, or any other sensitive data:

How we will contact you

The main Aglide domain is aglide.com. When we contact you, it will most likely be from support@aglide.com, however we do own more domains that we could contact you from. These are:

algide.io

aglide.co

aglide.ai

aglide.co.uk

aglide.xyz

aglidesso.com

tryaglide.com

aglidehq.com

We will never ask for passwords or 2FA codes from you. Never provide your master password or any 2FA codes to anyone, even if it appears to be communication from a legitimate source. If you believe someone is attempting to impersonate us, please notify us by emailing report@aglide.com asap, so we can notify other users.

Aglide Desktop

The Aglide Desktop app is required for Aglide SSO and can act as the user's SSO launcher. It's available for Windows, Mac, and Linux, and should only be downloaded from the link provided by your customer success agent.

Aglide Extension

The Aglide Extension acts as the Aglide Password Manager, and is required for Aglide SSO. It's available on the Chrome store (id: dcmjiahhddajbfccpbmcoolndcelloaf).

Aglide Dashboard

The Aglide dashboard is where users and admins can manage their accounts and access. It is only accessible at the link dashboard.aglide.com.

Handling emails.

Each user is given an email address, linked to their work email address. Aglide's Zero Trust model means very little is known about who owns each email, besides what address it is linked to.

When emails are sent to these addresses, Aglide determines if they could support SSO enforcement. If they can't, they are automatically forwarded to the linked email address. If they can, they're encrypted with zero trust, end-to-end, public key cryptography, and temporarily stored.

Aglide has never, and will never, bulk store and analyse your emails. It is impossible for Aglide, or anyone else for that matter, to read your stored emails.

Processing

Aglide email addresses are of the format [anonomousID]@aglidesso.com. When an email is sent to this address, the anonomous ID is used to recover the linked email address and public key. Email addresses are administratively encrypted at rest.

When emails are send to these addresses, they are checked against known emails that could support SSO enforcement. If there is a match, the email is encrypted, temporarily stored, and potentially forwarded to the user's workspace admin. If not, the email is forwarded to the linked email address, and not stored.

The purpose of Aglide email addresses.

Aglide Desktop is better able to perform certain functions (e.g., SSO, AutoMigration, etc.) when it has access to data from certain emails (e.g., confirmation links). As a result, relevant emails are stored so the Aglide Desktop app can access them when running these processes. As soon as an email is recovered by the app, it's deleted.

While your authenticated Aglide desktop app may need these emails, Aglide does not. That is why we are very selective about the emails we store, we store them in a way that ensures only the app signed in to by you can access them, and they are only stored temporarily.

It is impossible for Aglide, or anyone else for that matter, to read your stored emails.

Encryption and temporary storage

Each Aglide user has a public and private key pair. The private key is encrypted with the user's local key, meaning any data encrypted with the public key can only be decrypted by the user on their local machine (see section 2).

The main body of the email is encrypted with the user's public key using the RSA-OAEP standard. To allow for search, the subject, sender, and email category (e.g., password reset) are encrypted with the administrative key. The email is then temporarily stored in case it's needed for a local process, and deleted as soon as it is recovered by the desktop app.