Secret Key

Secret Key is an open-source, self-hosted emergency-access system for a password database. The product describes itself as a multi-layer password-database protection system: in a crisis, designated people reconstruct the master password and download the owner's password database, while access stays protected for as long as the owner is alive. The owner prepares the system once, and loved ones use it only in an emergency. It is built for people who store dozens of credentials — email, cloud photos, banks, subscriptions, crypto wallets — and who want a procedure that works where the law cannot help. The password database file stays on the owner's own server and is released only once the configured conditions are met. Secret Key does not replace a will or the inheritance process; the site states explicitly that it is not a legal tool and complements formal inheritance where access to accounts and 2FA codes would otherwise be lost. The problem Secret Key addresses is stated plainly on its website: each of us stores dozens of passwords for email, cloud photos, banks, subscriptions and crypto wallets, and it is unclear what happens to them after we die. The family gets cut off from email, photos, 2FA codes and cryptocurrency, and where the law cannot help there is no procedure at all. A will or an inheritance process can deal with money in a bank account, but it does not open an inbox, a photo library or a crypto wallet held on a personal key. Keeping every credential in one place with one person, or writing the master password on a note next to an encrypted USB stick, concentrates risk: the single holder may lose it, misuse it, or simply be unavailable when the family needs it most. Secret Key approaches this by making access a collective act that requires several people to appear together, with their own credentials, at the same time. The core mechanism is Shamir Secret Sharing. The master password of the password database is split cryptographically into shares, and the shares are handed to designated, trusted people. The website explains the mathematics: the secret is the constant term of a polynomial over the field GF(2⁸), and every share is a point on its graph; the required number of points can be reconstructed unambiguously by Lagrange interpolation. Fewer shares than the required threshold give no information about the secret — described as information-theoretic security — regardless of the attacker's computing power, and 1024-bit padding protects small secrets. Typical setups are 2 of 3, 3 of 5 and 4 of 7, with 3 of 5 recommended; the higher the threshold, the harder collusion becomes, but the harder it is to gather people in a crisis. The shares use the format of the secrets.js library, the same as iancoleman.io/shamir, so the reconstruction can be independently verified outside Secret Key. Even when the required number of people recover the password, the files stay locked for 48 hours. Secret Key calls this "we lock the file, not the password": Shamir's math stays untouched, and the password database file remains locked for the duration of the security window. After the first successful reconstruction the owner receives an e-mail telling them who did it, when, and from which IP address. That e-mail contains a Panic Button link that works without logging in — it is authorised by a random 256-bit token tied to that specific lock — so the owner can react from any device. If the reconstruction was not intended, one click blocks the files permanently; if it was planned, the files unlock on their own after 48 hours. This is the system's answer to trustees who collude and reconstruct the password without the owner's consent. The site lists nine independent protection layers, each working autonomously so that compromising one does not grant access to the system. Passwords are hashed with bcrypt at cost 10, with comparison resistant to timing attacks. Every state-changing endpoint carries a CSRF token of 64 hex characters. Attempt lockout allows 3 attempts per 15 minutes per IP and per account, with counters stored in a file rather than in cookies. SMS 2FA uses 6 digits valid for 10 minutes, with 60 seconds between sends. Trusted devices last 7 days using a SHA-256 token in an HttpOnly cookie. Sessions auto-log out after 30 minutes and the session ID is regenerated after verification. Interface protection includes developer-tools detection, DOM removal and a log entry with a REF# number. Downloads are gated: files live outside public_html and are served only by download.php. Finally, the 48-hour time-lock adds a download lock and a Panic Button with an e-mail alert. Overall the product follows a two-phase workflow. In setup, the owner configures the system in a dashboard that runs locally without the internet, adding people, downloadable files such as a KeePass database and instructions, with passwords hashed by bcrypt in the browser. The owner then splits the master password into Shamir shares (for example 3 of 5), uploads the app/ folder to public_html and the configuration to /private/ outside the public directory, and uses the generator to create cards as a PDF, testing login before handing them out. In an emergency, the required number of card holders meet; each logs in with their card details and confirms identity with an SMS code; everyone types their code or scans the QR code with a phone and pastes it into the panel, and the password is rebuilt locally in the browser. The files then wait out the 48-hour window while the owner is alerted, after which the password database and the app can be downloaded and the reconstructed master password opens the database in a password manager. Shares can be handed over in any format — a printed sheet, a PDF file, or a custom plastic card — as long as every carrier contains the same four elements: unique login credentials for each designated person with a phone number assigned for 2FA, the hex Shamir share fragment, an optional QR code encoding the same share, and the address of the owner's own Secret Key instance. The QR code removes manual-transcription errors when a code is scanned and pasted into the panel. Because the threshold design includes redundancy, one or two people being unavailable does not block the procedure as long as the remaining holders can reach the minimum number of shares, and a lost card is limited in risk because logging in also requires access to the phone assigned to that account. The architecture keeps data on the owner's own hosting: the dashboard runs offline on the owner's computer for setup and card generation, the server runs PHP 8+ with plain files, zero SQL and zero cloud, and the only external service is the SMS gateway SMSPlanet, which receives only the phone number and the text of the SMS with the verification code. In a crisis, loved ones' browsers handle login and password reconstruction using the card, SMS and Shamir shares; the server can verify the password if SECRET_HASH is set, otherwise the password never leaves the browser. The site also states the limits: physical access to the server, social-engineering attacks on card holders and a faulty web-server configuration on the user's side are outside the scope of the system, and Secret Key does not decrypt email or messengers — it only splits the master password of a password database such as KeePass or Bitwarden. Concrete scenarios follow directly from the site. A family needs access to the owner's accounts after a death: three of five card holders meet, log in with their cards and SMS codes, enter their shares, wait out the 48-hour window and download the database, which they open in KeePassXC using the reconstructed password plus the required hardware key. A trustee group tries to reconstruct the password without consent and the owner cancels the download with the Panic Button link from the e-mail. An owner prepares a separate emergency database containing only the accounts meant for the family, so private correspondence is not exposed. And redundancy covers the case where one designated person dies or becomes unavailable — the remaining holders can still reach the threshold. The system is aimed at technically comfortable owners who can run their own hosting and follow the offline dashboard and documentation, while their loved ones only receive cards and instructions. Setup is explicitly described as technical, with the dashboard and documentation simplifying it. The project is open source under the MIT license (version 3.1.3 on the site), links to GitHub and documentation, and accepts support through a project support page; the site presents no commercial plans, and KeePassXC is offered as the companion program to open the downloaded database file. The product's primary value is a protected, reversible emergency plan: the password stays split and useless piece by piece, access demands a quorum plus SMS confirmation, and the owner keeps a one-click way to stop it.