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 should-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