Skip to main content
MicaraVault

What we cannot protect you from

This page exists because a security product that only lists its strengths is misleading its users.

MicaraVault is not unhackable, and it is not “100% secure”. What it is: a design in which our servers cannot decrypt your data, so a breach of our infrastructure does not expose your secrets. That is a strong and specific property. It is not the same as invulnerability.

A compromised device

Malware, a keylogger or screen-recording software running as you can capture your master password as you type it and read your vault while it is unlocked. No password manager can prevent this. Your device’s security is the foundation everything else rests on.

A malicious browser extension

Any extension with permission to read pages on this origin can read your unlocked vault. Audit what you have installed. For your most sensitive material, prefer a native client.

A hostile server serving hostile code

The web app’s JavaScript comes from our servers. If they were compromised and served modified code, that code could capture your master password before encryption happens. We mitigate with a strict CSP, subresource integrity and reproducible builds — but a pure web client cannot fully solve this, and neither can any other browser-based end-to-end encrypted product.

A weak master password

Argon2id makes guessing expensive, not impossible. If our database were stolen, an attacker could attempt offline guesses. A short or common master password will eventually fall. This is the single largest variable in your account’s security and it is yours to control.

Losing everything

Lose your master password and every recovery method, and your vault becomes permanently undecryptable. We cannot recover it. Support cannot view it. There is no backdoor — that is the point.

Your email account

Two flows send a link to your address: signing in by email, and approving a new device when you have no trusted device left. Both are weaker than the paths they supplement. Someone with your mailbox could sign in as you and see that items exist — they could not read one. Every stored value is encrypted under keys derived from your master password, which no email carries and no server can reconstruct. If that trade is not one you want, do not use email sign-in, and turn on an authenticator app: two-factor is enforced on both paths.

Metadata

We see structure even though we cannot see content: how many vaults and items you have, item types, approximate sizes, when you are active, your IP addresses, and who you share with.

The clipboard

When you copy a password, other applications and operating-system clipboard history can read it during the window before we clear it. We shorten that window and show a countdown. We cannot close it.

Memory erasure in JavaScript

We overwrite key buffers when the vault locks, but a JavaScript engine may have copied them during garbage collection or JIT compilation. Erasure is best-effort in a browser.

Data already shared or downloaded

Revoking a share stops future access. If the recipient already decrypted and saved a copy, that copy is theirs. We say this on the revoke dialog rather than implying a remote wipe we cannot perform.

Malware inside files you upload

We cannot scan encrypted files server-side and we do not pretend to. Scanning is client-side, before encryption, and optional; the status is recorded and shown on the file.

Future cryptanalysis, including quantum

X25519, used for sharing, is not post-quantum secure. An adversary recording sealed vault keys today could open them given a sufficiently capable quantum computer. Our symmetric layers retain more margin, and algorithm agility is built in so we can migrate.

What the architecture does guarantee

  • A full compromise of our database, storage, servers and operator accounts yields ciphertext and metadata, not plaintext.
  • Keys are derived on your device from a password we never receive in any form.
  • Authenticating to our server does not enable decryption; the two secrets are cryptographically separate.
  • Every ciphertext is authenticated, so tampering is detected and a failed check returns nothing rather than something wrong.
  • Deletion destroys keys, so deleted data is undecryptable even where bytes persist in a backup.
  • Emergency and organisation recovery are opt-in, visible and audited. There is no hidden administrative backdoor.
  • Every claim above is testable, and the tests are in the repository.

Found a way around any of this?

Tell us. We pay for findings and we publish advisories.