We commonly share passwords within the organization and would highly prefer that the TOTP key be hidden all the time or at least while shared. This poses a security risk in the event a staff member is let go and they’ve copied the TOTP key. Maybe I’m being paranoid, but it doesnt seem like it should be visible.
Totally not paranoid … 
We get it 
It’s on our roadmap to make this an option.
1 Like
Nope no paranoia here at all.
Glad to hear its roadmapped!
1 Like
Hi @all,
today I want to request a feature that concerns using BW in a team.
What do I have?
We are working in an IT company and we are using BW to manage account in our team. So far so good. We are using accounts of our customers to get access to their systems for maintenance, we are using accounts for support portals, and so on. All these accounts are used by multiple members of my team and for most of these accounts 2FA is activated. To let the user use TOTP within bitwarden I have to let him see passwords, I can’t hide them. That’s not a problem because sometimes it’s needed to see credentials if the login isn’t possible via auto-fill. But: If the user can read the credentials he can also read the TOTP seed.
What do I want to achieve?
I want to discuss the fact that sometimes members leave the team. Of course, I will disable his account in BW. But what if the leaving member copied all seeds before he left the building? I don’t want to change hundreds of passwords only if one member is leaving the team. I want to achieve the user is not possible to copy the seeds but should be able to see passwords and TOTP codes because this is needed for day-to-day operations. Keep in mind that exactly for this requirement hiding the passwords is not a solution.
What is my idea?
It could be easy: Just let only administrators see and change the seed of a TOTP entry and show only the TOTP code to all other rule levels.
I really what appreciate it if this could be a feature you can add. I’m really happy with BW using the payed version with my team, but the management of TOTP in this matter is not optimal. And yes: I know that fact that storing the TOTP at the same place could lead to a reduction of security but if we only use accounts with a minor impact if they get compromised this could be the way.
What do you all think, wouldn’t it be worth making BW a bit more secure in handling TOTP in teams/companies?
Brgds
Lutz
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
Correct, the TOTP master key is the 2nd factor and must not be accessible to users, I do not understand how security product exposes it to the public.
I have changed the title of this Feature Request topic (was: “Obfuscate TOTP Authenticator Key”) to better distinguish it from the Feature Request Authenticator Key (TOTP) toggle visibility option. The proposals in the current thread express a preference for controlling all access to the TOTP Authentication Key, whereas the other proposal is simply to allow the user to shield TOTP Authentication Keys from the eyes of shoulder-surfers (similar to the way that passwords are obfuscated).
@alonbl Welcome to the forum!
I switched the location of your longer post, since it is more relevant to this Feature Request than to the other one.
Thanks @grb, I hope this will assist in pushing this forward. TOTP key (seed) should not be exposed to the user/client, it should not be downgraded to a password.
Hello,
I already sent this to Bitwarden support, pasting it here as well.
I can think of several implementations to handle the OTP code without exposing the OTP seed, first we need a feature…
Bitwaden Core Feature: OTP code derivation service hook
Add a feature to specify OTP code derivation service as external Restful service with two methods:
- Seal OTP seed
- Derive OTP code out of sealed OTP seed
Authentication will performed using short term public key signed JWT issued by Bitwarden based on the vault access permission.
The service serve as a driver to provide a custom logic to perform the seal and derivation.
We may need to modify OTP seed field in vault to be opaque long string instead of structured one as sealed seed may be long.
The existing implementation will be applied, if no Restful OTP derivation service URL is registered.
openapi: 3.0.0
info:
title: OTP derivation service
description: |-
This is an example of OTP derivation service that may be used
by password managers to derive OTP code while not exposing the
OTP seed to the client.
contact:
name: Alon Bar-Lev
email: [email protected]
version: 0.0.0
paths:
/sealOTPseed:
post:
summary: Seal OTP seed
description: Seal a OTP seed by the service keys
operationId: sealOTPseed
requestBody:
description: Seal a OTP seed by the service keys
content:
application/json:
schema:
type: object
required:
- seed
properties:
name:
type: string
description: a name for the seed
type:
type: string
default: TOTP
seed:
type: string
example: SFDF3 SFDF3 SFDF3 44FS G432
algorithm:
type: string
default: SHA1
tokenLength:
type: integer
default: 6
required: true
responses:
'400':
$ref: '#/components/responses/UnsupportedOTP'
'401':
$ref: '#/components/responses/UnauthorizedError'
'200':
description: Successful operation
content:
application/json:
schema:
type: object
properties:
sealedSecret:
type: string
example: cGFzc3dvcmQcGFzc3dvcmQcGFzc3dvcmQcGFzc3dvcmQ
/deriveOTPtoken:
post:
summary: Derive OTP token
description: Derive OTP token out of sealed seed
operationId: deriveOTPtoken
requestBody:
description: Derive OTP token out of sealed seed
content:
application/json:
schema:
type: object
properties:
sealedSeed:
type: string
example: cGFzc3dvcmQcGFzc3dvcmQcGFzc3dvcmQcGFzc3dvcmQ
required: true
responses:
'400':
$ref: '#/components/responses/InvalidOPTSeal'
'401':
$ref: '#/components/responses/UnauthorizedError'
'200':
description: Successful operation
content:
application/json:
schema:
type: object
required:
- token
properties:
token:
type: string
example: 123456
expiration:
type: string
format: date-time
sealedSeed:
type: string
description: |
A new seed to be provided in next iteration
This is an advanced feature which requires writable
vault at user side.
example: 3112332c3dvcmQcGFzc3dvcmQcGFzc3dvcmQcGFzc3EErrdvcmQ
components:
responses:
UnauthorizedError:
description: Access token is missing or invalid
UnsupportedOTP:
description: OTP settings are unsupported or invalid
InvalidOPTSeal:
description: The provided OTP seal is unsupported
securitySchemes:
bearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
security:
- bearerAuth: []
Bitwaden UI Feature: OTP user interface modifications
- User enters OTP seed:
- If no OTP code derivation service URL is registered to the collection/object: store the OTP seed as-is
- Else: Send the OTP seed to the service seal method and apply the output as OTP seed in vault
- User resolves OTP code:
- If no OTP code derivation service URL is registered to the collection/object: Derive the OTP code from the OTP seed locally.
- Else: Send the OTP seed to the service and apply output as OTP code
Advanced:
When user enters TOTP seed, user may choose to enter the sealed seed instead of the plaintext, when entering the sealed seed there is no need to call the service.
Solution principals
- Do not modify current product behavior, if no OTP code derivation Restful URL is provided the current logic applies.
- Access control to the OTP seed will be managed by the Bitwarden, no change in this regard.
- Implementation may choose not to make the OTP seed available at client side.
- OTP seed is not available to Bitwarden (aka zero-knowledge), unless Bitwarden implements an OTP code derivation Restful service.
- There may be multiple OTP code derivation services deployed each one may protect different set of keys if it will be possible to specify a URL per collection/entry.
Restful OTP code derivation service implementation
AWS based example of customer’s Restful service implementation:
- AWS lambda that uses KMS CMK to encrypt the OTP seed and metadata and encode using base64.
- AWS lambda that implements the Restful interface to validate the Bitwarden ticket and decrypt the TOTP seed and metadata and derive the code.
Enclave based example of Restful service implementation: Instead of lambda + KMS use enclave + platform generated key, this can run within HSM or within other secure environments such as Intel SGX.
Bitwarden may provide a default implementation of the OTP code derivation service, the default implementation will use Bitwarden CMK encryption, it may be as secure as the device Bitwarden uses. As Bitwarden have access to the OTP seed but not to the password, it still provide a good separation of concerns, better than having both the password and the TOTP seed exposed to the client.
In any case this implementation will allow customers to replace the service with their own implementation.
There may be more complex solution in which code derivation can be done using keys that are derived from Bitwarden and the customer, however, I think the above outlined solution is simple and provides a decent solution.
Regards,
Alon Bar-Lev
I’m honestly shocked the TOTP auth key is available to just copy out like this. It’s fine for consumers but really has no place in the enterprise or MSP space. An employee could easily copy this key and duplicate the TOTP authenticator elsewhere :S
An easy and optional way to resolve this would be via Policies:
Hide Authenticator key (TOTP)
Do not allow members to view the Authenticator key (TOTP) once set – edit is still possible.
I share your shock … and I am doubly shocked that a fix for this obvious security issue has been requested by multiple people for years and still remains a vulnerability.
Is it possible to simply lock the ‘Authenticator key (TOTP)’ field with a ‘Master password re-prompt’ checkbox?
I would like to use this handy feature, but can’t while it is easy for a bad actor to steal my authenticator keys.
Alternatively, it should be designed like all other TOTP code generators - enter the authenticator key, then you can never see or access it again. If lost, it has to be recreated through re-registration with the originating website service.
Yes, if you enable “‘Master password re-prompt”, then this will lock UI access to the “Authenticator key (TOTP)” field.
My thought was to lock the TOPT authentication key field itself, not the whole login account, as the ‘Master password re-prompt’ checkbox is currently configured to do.
However, I realized neither option is a satisfactory solution, because both negate the ease-of-use.
If the ‘Master password re-prompt’ checkbox is checked at the:
1/ Account level: Have to enter master password twice - once for the username and then again for the password.
2/ TOTP field: Would still require entering the master password to copy the TOTP code to clipboard.
It should be designed like all other TOTP code generators - enter the authenticator key at registration time, then you can never see or access it again. If lost, it has to be recreated through re-registration with the originating website service.
Combining the two factors of authentication (password + TOTP) into one does streamline ease-of-use, but even if authentication keys were hidden, it is at the expense of the added security that comes with the physical separation of the factors. Exposing the authentication keys increases security risk by an order of magnitude yet again.
I asked Google Gemini AI app:
“Does creating an OATH TOTP code generating app that leave authentication keys visible break OATH architecture?”
It responded:
"Yes, creating an OATH TOTP code generating app that leaves authentication keys visible breaks the OATH architecture in a critical way. Here’s why:
OATH for Secure Authentication:
The core purpose of OATH (Open Authentication) is to provide a secure way to generate one-time passwords (OTPs) for two-factor authentication (2FA). This security relies on keeping the secret key used for generating OTPs confidential.
Visible Keys Compromise Security:
If an app leaves the authentication keys visible, anyone with access to the device can see them. This defeats the entire purpose of using a secret key, as it can be easily copied or stolen. A malicious actor with the key could potentially generate valid OTPs and bypass 2FA for your accounts.
Potential Attacks:
Here are some potential security risks associated with visible keys:
Physical Access:
If someone gains physical access to your device with the app running, they can steal the visible key and bypass 2FA for your accounts.
Malware/Spyware:
Malicious software on your device could potentially steal the key from the app’s memory or storage.
Shoulder Surfing:
Someone might be able to peek over your shoulder and see the key displayed on the screen.
Secure OATH Implementations:
Limited Key Display:
Reputable OATH TOTP code generators typically only display the generated OTP itself, not the underlying secret key. The OTP code is temporary and expires after a short period, minimizing the risk even if someone sees it briefly.
Secure Storage:
Secure OATH implementations store the secret key in a secure enclave on the device’s hardware, making it difficult for unauthorized access.
In Conclusion:
An OATH TOTP code generating app that leaves authentication keys visible fundamentally undermines the security benefits of OATH by compromising the confidentiality of the secret key. It’s crucial for such apps to prioritize secure key storage and display only the temporary OTP codes for optimal security."
Microsoft Co-Pilot AI app response:
"Best Practices:
Protect Secrets:
Developers should ensure that secret keys are stored securely within the app, ideally encrypted or obfuscated.
User Education:
Educate users about the importance of safeguarding their authentication keys.
Multi-Factor Authentication (MFA):
Consider implementing MFA alongside TOTP for enhanced security.
In summary, while visible authentication keys don’t inherently break the OATH architecture, it’s crucial to handle them securely to maintain the integrity of the authentication process."
Correct me if I am wrong … but I do not believe I received any ‘AI hallucination’ in the above responses.
One of them must be hallucinating, because they arrived at opposite conclusions… 
1 Like
This needs to be escalated to decision makers who take the issue seriously.
I do not use the TOPT feature because of that issue. I use double-blind passwords, so my real passwords are not stored it Bitwarden.
But this issue raises the broader question of development discipline, and how many other problems may be lurking under the bonnet that users may be vulnerable to.
1 Like
While I can see the need for an organisation to secure keys to help manage departures, for individuals such security seems more of an obstruction to normal use.
The AI answers worked on the assumption the key was visible, and mentioned shoulder surfing.
- When I login to a site which used TOTP, the key is not visible in either the browser extension or the desktop app.
- The key does not appear unless I edit the login; fairly unusual, and not something I do in the view of others.
- A shoulder-surfer will have to be pretty skilled to memorise a key accurately in the time likely to be available.
The rest is normal security, locking or logging out of the vault. If a person is concerned about the risk of Bitwarden holding TOTP and key (one might reasonably dislike both password and TOTP being in the same place) they can use a separate authenticator (and store the key where they please).
It also seems to me that peppering, ‘double-blind passwords’, is of less utility than it first appears. The relevant case is that an attacker knows the rest of your password(s), in which case a short string or words will be little harder to crack than they would be if the major part of the password did not exist.
One could be ‘tricky’ about manipulation and insertion of the pepper, at direct cost to convenience, but is this really the major security threat? Exposure of secrets through human error seems to me somewhat more likely.
One way of accomplishing that would be to get a few more votes. Currently, this feature request only has 7 votes, placing it in about 500th place.
I personally do not understand how this is an effective mitigation. To generate a TOTP, the secret key needs to be accessible to the process that generates it. This process runs with the user’s permissions, so the secret can be attained by inspecting process memory. Obscuring it in the GUI is nothing more than cosmetic.
If a team member leaves your organization, the proper reaction is to change all passwords to which they had access. Anything less is not an effective mitigation.
I do get that changing “hundreds” of passwords is a lot of work. That is why you ought to arrange for people to not need so many passwords. At my company, we accomplish this with SSO, sudo, and privileged account managers, (e.g. Cyberark or SecretServer – both of which can rotate thousands of passwords on a scheduled basis, after use, or even upon demand).
1 Like
Thx for your recommendation, but if you think about the non-personalized accounts that we use for the administration of the systems of our customers where we often can’t change the accounts on our own and have to ask our customers, this leads to a big effort. You think too strong about the password only. Independed from the request here, in general the seed should not be accessible in that way. And please take into consideration that the user itself is only using the credentials stored in Bitwarden, the can’t setup MFA OTP on their own. This has to be done through an admin with elevated rights in BW. So no, there is no need to espose the otp secret to every user.
And your recommendation to use another tool only leads to more effort and money and that because of a small feature that is missing in BW. To be honest: Yes, I can use multiple tools for everything, but why should I if a small change solves the issue.
Last but not least let me mention the the password itself lost the importance in world where MFA should be used everywhere. No, changing the password isn’t the way needed if I have MFA in place, because the “have” component isn’t know for the user only for 30/60 seconds. Because of the well known and worldwide confirmed situation that passwords (know component) are often compromised,leaked,cracked, etc. MFA was established and strong password policies are not recommended anymore and are weakening the security.
I stay with my meaning the hiding the OTP secret is a strong need for a sec product like BW.