2Secret 1.9.4

Security improvements from a review of the cryptography against a stolen server database, a stolen device and a hostile server.

• Known keys. The apps and the command line remember the public keys of everyone you sealed a vault key to (sharing a vault, replacing its key, an emergency contact). When the server later reports other keys for that person, nothing is sent to them and the app shows both fingerprints; you can trust the new keys after comparing them (2secret account trust-keys on the command line). Until now a server could put its own keys in someone's place, for an emergency contact even without you doing anything.
• Replaced vault keys. A vault key that the server offers sealed to your public key for a vault without other members is refused: only your own devices could replace that key, and they do so with your account key. Every replaced or refused key is mentioned after the sync.
• Mac: the Touch ID key is in the protected keychain. The key that unlocks 2Secret with Touch ID was in the login keychain, which has no Touch ID protection of its own, so a copy of the Mac's disk opened with the login password alone. It is now a keychain item that the Secure Enclave releases only after Touch ID with the enrolled fingers, on this Mac, like on the iPhone. The app moves the key on the next unlock. (On the iPhone the key was already protected this way; if that protection cannot be set up, the key is now not stored at all.)
• Server: the database keeps a hash of each share link's proof instead of the proof itself, so a copy of the database can neither open a link nor use up its views. Links made before this version keep working.
• Server: the per-address count of failed sign-ins is forgotten after its window, like the other limits.
• docs/SECURITY.md says more precisely what the server stores and which limits apply.
• Dependencies: tokio 1.54.1 (RUSTSEC-2026-0386), clipboard-win 5.4.3. The advisory on crypto-bigint 0.5 (RUSTSEC-2026-0387, timing variability in P-256 arithmetic) waits for ssh-key 0.7; P-256 only signs on the device, after a click or consent (see deny.toml).
• The iOS simulator check looks for the app's process directly instead of asking launchctl, which once took too long on a busy runner.

Downloads#

Server image for x86_64 and ARM64 (e.g. Raspberry Pi 4/5 with a 64-bit OS): docker pull ghcr.io/joostiphone/2secret:latest – see self-hosting.

On macOS, drag 2Secret to Applications and open it. If macOS says it cannot verify the app, open System Settings → Privacy & Security and click Open Anyway (on macOS 14 and older you can also right-click the app and choose Open). On Windows, SmartScreen may ask you to confirm (More info → Run anyway).

FreeBSD, OpenBSD, NetBSD and iOS: build from source, see the README.