Argon2id and AES-256-GCM: how your vault is encrypted

In short: Argon2id is a deliberately slow, memory-hungry function that turns your master password into an encryption key. AES-256-GCM is the cipher that encrypts your vault with that key and detects any tampering.

Secure It Password Manager does both on your device, with Argon2id from libsodium. Secure It is a zero-knowledge password manager that stores your encrypted vault in your own Google Drive: no company servers, not even ours. The file in Drive is unreadable without your master password or your recovery phrase.

This page explains each step, what the standards say, what we state about our own implementation and what we don't. Facts were checked on 19 Oct 2026.

Crypto spec at a glance (as of 19 Oct 2026)

We would rather leave a number out than guess it. When we publish the exact parameters, they will go in this table.

The two steps: derive a key, then encrypt

1. Derive. Your master password goes into Argon2id together with a random salt. Out comes a 256-bit-class key. Nothing about this step needs a server.
2. Encrypt. The vault is encrypted with AES-256-GCM using that key. The result is ciphertext plus an authentication tag.
3. Store. The ciphertext is saved on the device and, if you turn on sync, uploaded as vault.enc to your own Google Drive.
4. Unlock. Typing the master password repeats step 1. If the key is right, the tag verifies and the vault opens. If anything is wrong, decryption fails.

The master password is never stored or sent. This is what "zero-knowledge" means in practice; our zero-knowledge explainer covers the term in more depth.

Why Argon2id

A master password is short compared with a random key, so an attacker who steals an encrypted vault can guess passwords offline, as fast as their hardware allows. A key-derivation function makes each guess expensive.

Older functions such as PBKDF2 are expensive in CPU time only. A GPU or custom chip can run thousands of them in parallel cheaply. Argon2 is memory-hard: each guess needs a large block of RAM, which is costly to replicate thousands of times over.

Argon2id is the variant to use for passwords. RFC 9106 describes it as a hybrid of the other two: for the first half of the first pass over memory it uses data-independent addressing (like Argon2i), which resists side-channel attacks, and after that it uses data-dependent addressing (like Argon2d), which makes time-memory trade-offs harder for a cracker. The RFC says implementations must support Argon2id.

What the standards recommend

• OWASP (Password Storage Cheat Sheet) lists Argon2id first and gives a minimum configuration of 19 MiB of memory, 2 iterations and 1 degree of parallelism. It lists equivalent trade-offs, such as 46 MiB with 1 iteration, or 12 MiB with 3 iterations.
• RFC 9106 gives two parameter sets for Argon2id: 2 GiB of memory with 1 pass and 4 lanes when memory is plentiful, and 64 MiB with 3 passes and 4 lanes when it is limited.
• libsodium, the library we use, makes Argon2id its default password-hashing algorithm and ships preset tiers. Its documentation puts the "moderate" tier at 256 MiB of RAM and about 0.7 seconds on a 2.8 GHz Core i7, and the "sensitive" tier at 1024 MiB and about 3.5 seconds (libsodium docs).

Argon2id vs PBKDF2

OWASP's PBKDF2 guidance is 600,000 iterations with HMAC-SHA256, or 220,000 with HMAC-SHA512, and it recommends Argon2id when you can choose. PBKDF2 is still acceptable where compliance requires FIPS-140 approved algorithms, but for a new design with a free choice, memory-hardness is the better defence against GPU cracking. We chose Argon2id.

Why AES-256-GCM

AES-256 is the AES block cipher with a 256-bit key. GCM (Galois/Counter Mode) is a mode of operation that provides authenticated encryption: it keeps the data confidential and also produces a tag that proves it has not been modified. NIST specifies GCM in SP 800-38D (published November 2007; NIST has announced a revision).

The authentication matters for a vault. If someone alters the stored file, or a sync glitch corrupts it, GCM decryption fails instead of quietly producing garbage or letting an attacker flip bits.

The nonce rule, in plain language

GCM needs a number called a nonce (or IV) for every encryption, and the one hard rule is that the same key must never be used with the same nonce twice. Reuse breaks GCM's guarantees. Implementations avoid this by generating nonces correctly and by using fresh keys or salts. NIST's document defines the requirements. We have not published our nonce handling in detail yet, so we don't make claims about it here.

What the master password still has to do

Argon2id slows guessing, but it can't rescue a weak password. If your master password is on a common-password list, a cracker tries it first and the cost per guess barely matters.

NIST's SP 800-63B is a good guide to choosing one:

• Length matters most. It sets a minimum of 15 characters for passwords used alone, and 8 where multi-factor authentication is also required.
• Services should allow at least 64 characters.
• Composition rules (forced symbols and capitals) are discouraged.
• Passwords should be checked against lists of common and breached passwords.

In practice: use a long, unique passphrase that you've never used anywhere else. Our app's generator can make one.

What sits in your Google Drive

With sync on, Drive holds one file: vault.enc. It is ciphertext. Google can see that a file exists, and its name, size and timestamps, as it can for any file. It can't read the passwords inside, because the key comes from your master password, which we never receive.

We request the drive.file scope. Google's documentation describes it as letting an app "create new Drive files, or modify existing files, that you open with an app", and classes it as non-sensitive and recommended for most uses (Google Drive API docs). In plain terms, the app is not given access to your whole Drive.

Sync is optional. A vault works fully offline on one device without any account. A Google account is needed only to use the same vault across Android, Windows and the browser extension.

Compare that with a vendor cloud. Bitwarden's cloud accounts are stored in Bitwarden's cloud in a US or EU region, and 1Password hosts account data in the region you pick at sign-up. Both encrypt on the device too. The difference is that those vaults sit together on the vendor's servers, whereas ours don't exist: each person's encrypted file is in their own Drive.

What this does not protect against

Strong encryption has limits, and we'd rather state them:

• Malware or a keylogger on your device. If an attacker can watch you type or read memory while the vault is unlocked, encryption at rest doesn't help.
• A weak or reused master password. See above.
• Phishing. You can still type a real password into a fake page.
• Losing both your password and your recovery phrase. There is no server-side reset, by design.
• No independent audit. Secure It has not had an independent third-party security audit yet. We use named, standard primitives and say what they are, but you can't verify us from an audit report. Bitwarden and 1Password, for example, publish theirs. We are also a small, independent developer, not a large security company.

Recovery

Because we can't reset anything, recovery is in your hands. Every user gets a 12-word recovery phrase (BIP-39 format) and an Emergency Kit PDF that includes an offline recovery script. Keep both offline. Anyone who has your phrase and your vault file can get in.

Competitors are blunt about the alternative. Bitwarden states it "has no way to access, retrieve, or reset your master password", and Dashlane says that without a recovery method set up it cannot help you regain access. We give you the tools before you need them.

Availability

The Windows app is free on Microsoft Store and the Chrome extension is free on the Chrome Web Store; both are unlocked by the one-time Android purchase on Google Play (US$4.99, local prices vary). Android is currently in closed testing. There is no iOS app yet; it is coming soon with no date. See downloads and pricing.