Short answers to the questions people actually ask.

Every credential field is encrypted on disk with AES-256-GCM - the same authenticated cipher used by Signal, WhatsApp, and modern TLS. Authenticated means tampering with the encrypted bytes is detected on decryption rather than producing scrambled output.

The encryption key is derived from your master password using Argon2id - a memory-hard algorithm that allocates 64 MiB of RAM per attempt. Memory-hard means it can't be cheaply parallelised on GPUs or rented cloud farms the way older algorithms (like PBKDF2) can. Even with your encrypted blobs in hand, brute-forcing a decent password is unrealistic on consumer hardware.

Each individual field - title, username, password, URL, notes, custom fields, TOTP secret - is also bound to its row and column when encrypted, so an attacker who somehow tampered with the database file couldn't swap one field's encrypted blob into another column or another account.

Nowhere. We don't store it as plaintext, as a hash, or in any other form.

To check whether the password you typed is correct, 1Key keeps a small verifier - a piece of ciphertext that only the right password can decrypt. The verifier itself is stored in EncryptedSharedPreferences, which is encrypted at rest by a key bound to your phone's Android Keystore (the secure hardware enclave, TEE / StrongBox). So even if someone extracted your phone's storage, they couldn't read the verifier blob without live access to the Keystore - meaning offline brute-forcing of your password is not possible.

Your data is unrecoverable. There's no "forgot password" link because there's no server and no recovery copy of your key anywhere. Only you can decrypt your vault - that's what makes it truly private.

Existing installs are migrated automatically on the first unlock after the app update:

• If your password verifier was using the older PBKDF2 algorithm, it's silently re-derived under Argon2id.
• Auth metadata (verifier, PIN hash, wrapped vault key) is moved from regular storage into EncryptedSharedPreferences.
• Existing credentials are re-encrypted in the background under the new HKDF subkey scheme with per-field authentication. Your updated_at timestamps are preserved.

You don't need to do anything - none of this changes your master password, your vault, or your saved credentials.

While the vault is unlocked, three things sit in memory: the encryption key, a lightweight index of your credentials (just titles, usernames, and tags - so the list and search feel instant), and whatever entry you currently have open.

Passwords, secure notes, and 2FA codes are never kept hot. They stay encrypted on disk and are only decrypted at the exact moment you open the entry that contains them - then released as soon as you navigate away.

The instant the vault locks, all three drop. Nothing decrypted survives a lock.

That delay is Argon2id allocating 64 MiB of RAM and running three passes over it to turn your master password into the encryption key. The slowness is the feature - it makes guessing your password too expensive to be practical, even for an attacker with serious hardware.

Locally on this device, in an encrypted database inside the app's private storage. Other apps on your phone can't read it. Nothing leaves the device unless you explicitly export a backup.

It goes with the app. Android removes the app's private storage on uninstall - your vault, your settings, everything. Export an encrypted backup first if you want to keep it.

No. The app has no internet permission, no analytics, no crash reporting, no telemetry. You can verify in Android Settings → Apps → 1Key → Mobile data & Wi-Fi: data usage is exactly zero, ever.

No. Your data never leaves your device, so there's literally no path for anyone - developer, Google, your network - to access it. Decryption requires your master password, which only you have.

Screenshots, screen recordings, and the Recent Apps preview can all capture passwords on screen. Blocking them prevents accidental leaks (or someone glancing at your phone). You can turn the block off in Security settings if you really need screenshots.

Biometric unlock provides the same full access as your master password. We ask for the master password once when you enable biometric, to make sure it's really you turning that shortcut on.

Wrong attempts are counted persistently - killing and reopening the app cannot reset them - and trigger escalating cooldowns:

Wrong attempts	Cooldown
3	30 seconds
5	5 minutes
10	1 hour

For PIN specifically: after 3 wrong PINs, the PIN unlock is disabled until you successfully enter your master password. This forces a real identity check before the easier shortcut resumes. Successfully entering the master password resets both counters.

Biometric attempts also have a 3-strike counter that triggers the same fallback - if biometric fails three times in a row, the next unlock has to be the master password.

By default, every 48 hours we re-prompt for the master password regardless of biometric or PIN. It's a safety check so you don't gradually forget the password the rest of your security depends on. The interval is configurable in Security settings (48 hours, 3 days, 1 week, or 3 weeks).

Accidentally deleting a credential you need is worse than briefly storing one you've deleted. The bin holds deleted items for 30 days by default (configurable: 1 week, 30 days, 6 months, 1 year, or never) so you can restore them. They're encrypted with the same protections as active items - the only difference is they're filtered out of normal views.

Yes, with a clear constraint. Turn on Sync in Settings - it writes an encrypted backup of your vault every time you unlock by typing your master password. Biometric and PIN unlocks do NOT trigger a backup, by design: those unlock methods do not hand the app your password, and we will not invent a workaround that stores a copy. See the Sync section below for the full picture.

If you'd rather back up explicitly, the manual Export now button in Settings does the same thing on demand. Either path requires your master password.

An encrypted .1key backup is locked with your master password - useless to anyone without it. JSON or CSV exports are plain text - anyone who finds the file can read your passwords. Use encrypted backups unless you're migrating to another app that can't read the encrypted format.

The encrypted backup format also binds the export timestamp and your vault's version counter into the encryption authentication tag, so a backup file can't be silently tampered with, swapped for a different file, or replayed against a newer vault state without detection.

Yes. Export an encrypted backup from this device, install 1Key on the new one, and choose "Restore from backup" during setup. The backup password becomes your new master password.

It writes an encrypted backup of your vault to a folder you pick, each time you unlock the app by typing your master password. You see a small "Syncing..." bar at the top, then "Synced" with a tick, then it disappears. That is the whole feature.

Backups have to be encrypted with your master password. When you unlock with biometric or PIN, the app does not have your master password - by design, we never store it. So there is nothing to encrypt a backup with on those unlocks, and we will not invent a workaround that stores a copy. Type your master password to trigger a sync, or use Export now from Settings if you need an on-demand backup.

No. The app uses your master password only in the brief moment between you typing it to unlock the vault and the backup file being written. As soon as the encryption finishes, the memory holding the password is zeroed - the same way the existing manual export works today. Nothing about Sync requires us to keep your password anywhere on the device.

A folder you pick when you turn the feature on. It can be local storage, a USB drive, or a folder synced by another app (Google Drive, Dropbox, Nextcloud, OneDrive, etc.). The file is encrypted with your master password before it leaves the app, so the cloud provider sees only random bytes. The filename is fixed: vault-backup.1key.

No. The file is AES-256-GCM ciphertext under an Argon2id-derived key from your master password. Without the password, the file is indistinguishable from random bytes. What the cloud provider can see is metadata: the file's name, its size, and the time you uploaded it. If those signals matter to you (for example, the upload cadence reveals when you typically use the app), keep backups on local storage or a USB drive instead.

Sync is meant as a continuously fresh copy, not a version log. Each sync replaces the previous vault-backup.1key safely - we write to a temp file first and only swap it in once the full file is on disk. If you need a history (e.g. before a big change or before changing your master password), do an Export now to a different filename. Most cloud providers (Google Drive, Dropbox) also keep file version history on their side for at least 30 days, which gives you a rollback if you need one.

No. The vault unlocks and the UI is responsive immediately. Sync runs in the background; only the small bar at the top shows it is happening. A typical sync takes one to three seconds depending on your vault size and storage speed.

You'll see an amber "Backup didn't save" bar that auto-dismisses after a few seconds. Tap the bar to see the exact reason in Settings - common causes are the chosen folder being unreachable (cloud app uninstalled, USB drive removed) or the device being out of free space. Your existing vault-backup.1key from the previous sync stays intact - a failed sync never corrupts the previous good one because we write to a temp file first.

No. 1Key still has no INTERNET permission - that has not changed. We write the encrypted file to a folder on your device. If that folder happens to be one another app synchronises to the cloud, the upload is done by that other app, not us. We never see the network.

Yes. The Sync file is the same format as the manual encrypted backup. Install 1Key on the new device, choose Restore from backup during setup, point at the file, and type your master password. Done.

Each sync writes a fresh backup encrypted with whatever the master password is at that moment. After you change your password, the next time you unlock with the new one and trigger a sync, the file gets overwritten with one encrypted under the new password. Until that next sync runs, the existing vault-backup.1key is still locked with the old password - if you still remember it, you can restore from that file. We do not re-encrypt or migrate older backups in place; only the next sync rotates them.

Yes. Sync backs up both your active credentials and anything currently in the recycle bin. Restoring from a backup brings the bin back in the same state it was at sync time - so anything you deleted but had not yet purged will reappear in the bin, ready to be permanently deleted or restored from there. This matches how the manual Export now flow already works; Sync is the same file format and the same data scope.

It stays exactly where you put it. The file is yours - 1Key only writes to it, never reaches in to delete or move it. If you reinstall and pick the same SAF folder, the next sync overwrites the existing file. If you reinstall and want to restore your vault, choose Restore from backup during setup, point at the file, and type your master password.

No, by design. The file is AES-256-GCM ciphertext under an Argon2id-derived key from your master password. We don't ship a separate decryption tool. To read it, install 1Key on any device, use Restore from backup, and enter your master password. The file format is the same as a manual encrypted backup - both restore through the exact same flow.

Yes, any time. Turning it off stops new backups and releases the folder permission. The existing vault-backup.1key file is left where it is - we do not delete your file. You can keep it, move it, or delete it yourself.

The clipboard is automatically cleared after 30 seconds so a copied password doesn't sit there waiting to be picked up by another app. On Android 13 and above the copy is also marked sensitive, so the OS's paste-preview toast won't display the value.