Why LastBrowser Avoided isEncryptionAvailable on Linux
LastBrowser team explains why Electron's isEncryptionAvailable was insufficient for their Linux password vault due to basic_text fallbacks.
Stock photo for illustration only, not from the actual event
- LastBrowser builds a desktop browser on Electron with a local password vault.
- Linux lacks a single OS secret store, leading to fragmented desktop environment backends.
- The isEncryptionAvailable function fails to reveal the underlying encryption key type.
- Developers implemented strict gating and unknown-state handling during app startup.
Building a desktop browser on Electron involves securing saved passwords by encrypting them with Electron's safeStorage module before writing them to a per-profile JSON file on disk. On Windows, safeStorage utilizes DPAPI, while macOS stores the key in the Keychain, serving as reasonable local defaults for password vaults.
Linux, however, operates differently without a single operating system secret store. Electron selects a backend based on the specific desktop environment, such as gnome_libsecret for GNOME, Cinnamon, and XFCE, or kwallet variants for KDE sessions. If the environment is unrecognized or the application launches with the --password-store="basic" flag, it silently falls back to basic_text.
Stock photo for illustration only, not from the actual event
A detail easily overlooked in Electron documentation is that when no secret store is available, items stored via the safeStorage API remain unprotected, encrypted instead via a hardcoded plaintext password. Developers can detect this when safeStorage.getSelectedStorageBackend() returns basic_text. Consequently, encryptString() on Linux still executes successfully without throwing errors, even though the protection key is entirely public.
From a security standpoint, writing encrypted data using a known public key while signaling success creates a dangerous false sense of security. For password vault applications, this illusion of safety is often considered worse than lacking an encryption feature altogether, highlighting the necessity of deep OS-level backend verification.
Additionally, a minor timing issue complicates the process, as getSelectedStorageBackend() only yields valid results after Electron's app ready event. Calling it earlier returns an unknown status. To maintain robust security, the LastBrowser team decided to treat unknown statuses identically to disallowed states, preventing security decisions from being made on missing information.
"A vault that silently writes 'encrypted' passwords with a known key gives users a false sense of safety, which we consider worse than no vault at all."
LastBrowser Team
The implemented fix introduces a gate to evaluate the acceptability of the OS backend, combines this gating logic with app-ready checks, and utilizes a test file mocking safeStorage to verify the decision table. Looking forward, the upcoming deprecation and removal of synchronous safeStorage APIs in Electron 45 and 46 will require the team to adapt their fallback reporting mechanisms to asynchronous workflows.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment