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.
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.