-
Why is it possible to export TOTP secret (to KeePass file format) having only read permission? Is that by design?
-
Is that true that secrets are not safe to keep in Passbolt as bad actor can replace public key in DB, wait for the next secret update and steal it?
Thank you for your questions. Let me address each one in detail:
Exporting TOTP secret with read permission
Yes, this behavior is by design. Users with read access can export secrets because, in principle, if they can view the data, they can already copy it manually, or alternatively here inspect the javascript to see the seed. We’re open to suggestions here.
Replacing public keys and potential risks
You are correct that an attacker with access to the database could replace or add a user’s public key or permissions and wait to potentially access sensitive information. This risk is acknowledged in our security whitepaper:
An attacker with database access would be able to add themselves as a user (or replace an existing user public key), add themselves to a group, and wait for a user to share encrypted data with them. In the future, additional security could be put in place to sign user keys, for example, with an administrator’s key.
We are planning improvements to key distribution and signing in future versions of Passbolt to mitigate this risk, such as requiring user acknowledgement when a key is changed and signing other users’ keys with the current user key on first use (with manual confirmation). However, these measures will introduce additional complexity in the user experience, which may or may not be well-understood by users, potentially undermining their effectiveness. We welcome suggestions on balancing security and usability here as well.
It’s important to note that other password managers with collaboration features also face similar challenges when dealing with a compromised server. Since these systems also distribute public keys via the server, they are not immune to this type of attack, although the risk might arise at different stages or during different operations. These limitations are inherent to server-based systems with collaboration features.
Additionally, products like 1Password and Bitwarden are also vulnerable to attackers with server access who could inject malicious JavaScript to extract private key materials.
If your threat model includes protection against a compromised server that continues to be used for an extended period, finding a fully secure solution may be difficult. Server-based systems carry some level of risk in such scenarios.
Then, the claims about ‘End-to-end encryption’ on the main page are a bit misleading.