File
The vault sits inside an ordinary-looking PNG file.
A copied vault file should not open on someone else's device. BlindLock is built around that rule.
The vault sits inside an ordinary-looking PNG file.
Your password is required to open it.
The vault is bound to your authorised device. On other hardware, it stays closed.
BlindLock uses platform security hardware — TPM 2.0 on Windows and Linux, Secure Enclave on Apple devices and StrongBox on Android. A copied carrier is not enough: the master password and authorised device are also required.
If you want, activate a physical security key — a modern FIDO2 key that supports sealing, for example a YubiKey 5, a current Google Titan key, or a SoloKey. The key cryptographically seals your login. If it is lost, recovery requires an encrypted BlindLock backup and the separately stored recovery phrase.
Hardware binding protects the vault at rest. It does not replace operating-system hygiene and does not stop a keylogger on a computer that is already compromised.
A conventional local vault can often be copied and attacked offline with only the vault file and master password. BlindLock adds an independent device factor. Part of the unlocking key is derived inside your device's security chip and never leaves it in the clear. A copy of the carrier file therefore holds nothing but hardware-bound, encrypted content. Without that specific device, a piece of the key is missing, and the vault stays shut. Even if someone copies your PNG carrier from a backup or cloud-synchronised folder, the file alone is not enough: on unauthorised hardware the device factor does not match, and the master password cannot compensate for it. That adds an independent barrier instead of simply placing another password at the door.
Picture an old backup drive falling into the wrong hands. Among hundreds of holiday photos sits the PNG file that holds your BlindLock vault. The finder does not even recognise it as a vault: it has no telling extension and no fixed BlindLock header or vault marker. Even if they identify it and know your password, their machine is missing the device factor from your security hardware. The content remains encrypted, and the copied file alone cannot be unlocked. On your authorised device, the carrier and password can open the vault as usual, provided that no optional security key has also been required.
Device binding is an extra, honest hurdle, not a magic lock. It protects the vault at rest and makes copied files insufficient on unauthorised hardware. It does not replace a well-maintained operating system, a strong device sign-in or careful storage of your recovery phrase. On a computer already taken over by malware, even the best vault can be compromised at the moment you unlock it. We do not promise absolute invulnerability. We add an independent barrier and remove the classic weak point where one file plus one password opens everywhere.
Restoration on a new device requires an encrypted BlindLock backup and the recovery phrase shown during setup. Keep them securely and separately; neither is sufficient on its own.
Not automatically on two desktops. The binding is per device, and one paid lifetime licence activates exactly one Windows, macOS or Linux device. Simultaneous use on a second desktop needs another licence and its own hardware binding; migration uses an encrypted BlindLock backup and the recovery phrase. iOS, iPadOS and Android are always free.
No. The three-factor model of file, password and device stands on its own. The security key is an optional fourth factor for anyone who wants an extra physical confirmation.