Hello,
I am new to bitwarden and was very surprised that the key is presented, I do not believe this is discussed in via feature request domain and not as a CVE.
The password is “something you know”, the TOTP master key is “something you have”. The TOTP key must not be available to copy/past for anyone, even to the client, the TOTP value must be calculated at the server side. The TOTP key is the only factor that should prevent anyone from duplicate the credentials and login on behalf of the user, even if a key logger / camera or any other means steals the credentials that are being used by the user.
People above states that this is required for backup/recovery and transition to other form of TOTP management, this is correct, however, it should be handled within backup/recovery domain and not via the standard edit dialog. A user may also perform a recovery by re-enroll his TOTP key without the need to recover it at all.
If a backup/recovery is implemented, in organization it must be strictly limited to organization admin/owner, per the reasons expressed above.
To summarize:
- TOTP key must not be presented.
- A role should be added to allow TOTP key retrieval implemented as distinct sequence.
- TOTP retrieval role should be default to $owner, a none should also supported, enterprise account may force this value per organization.
- TOTP key should not be exposed to the client, so that the user or any application running on the client will not be able to generate future codes.
This is a major security venerability in the real world deployment use case of Bitwarden, it is not a software specific CVE but a deployment CVE that is common to any Bitwarden deployment leveraging TOTP.
Bitwarden Integration CVE: Credentials of users may be cloned by 3rd party, even when 2nd factor is registered into Bitwarden as the 2nd factor master key is accessible to the end-user instead of the derived code.
Regards,
Alon