OTP permissions. Create a specific permission or allow all users to view OTP.

Hello,
I have created an enhancement request for that.

Regards

Thanks.

Hi!

I'd love the ability to auto-fill the OTP in Web Login as well.

Also another security improvement suggestion: You shouldn't be able to copy the seed (key) of a OTP entry by default, because it weakens the 2FA and basically degrades it to a single factor again. When the seed stays secret, you need access to RDM/DVLS as a second factor. Without that restriction, you only need two pieces of information that you can copy, which is a single factor.

Hello,

Currently our plan is to make the generated OTP be visible with the Connect (execute) permission. This means that you will be able to remove the View Password permission on the entry, meaning the users won't be able to view the OTP's seed, only view the generated OTP value.

Regards,

That sounds like a workable plan to me. Thanks!

I believe the key should be hidden by default. By design of a one-time-password system, there's no reason the key should be readable by anybody except for generating the currect code. Assuming the code is generated on the client, this is only a GUI change (The key field should be write-only). Otherwise, users would have to set custom permissions on every OTP entry, which nobody is going to do. The secure option should be the default!

The even more secure option would be to generate the OTP on the server (datasource) and never even send the key to the client. But that wouldn't work with RDM local data sources or offline mode. It would be nice for DVLS + Web Login though!

Thanks!
Daniel

Hello Daniel,

With the changes we will do regarding being able to generate the OTP (basing it on the Connect (execute) permission instead of the View Password permission), this means that by default, your users will not be able to view the seed to generate the OTP, as the View Password permission is not enabled by default.

Default permissions at the vault level:


Default permissions with an OTP entry:


As you mention, currently the code is generated on the client. It's an interesting idea that you have regarding generating it on the server so that RDM never has access to the information to generate it. I will forward this information to our other teams so we can see whether this is something we can include in the future.

Regards,

Hi all, unless I'm misunderstanding the comments in here, does this apply to embedded OTP objects too? I want staff to be able to view the primary password of the credential and the embedded OTP generated code, but NOT the seed/key.

Hi!

I didn't know the "View password" permission was disabled by default, but I assume most of the time it will be allowed because users need passwords to be able to do their work.
In this case, we still would have to remove the permission from every OTP entry manually, so I don't know if that's the best solution.

The key should stay secret regardless of any permission. This is by design of any one-time password. If you can read the seed, it's no a second factor but just a second password that you can just copy. The whole point of a one-time password is that it is bound to a device which cannot be copied, and I think this should be true even in RDM. Of course this is hard to implement in a shared database, but it should at least be locked down in the GUI.

@justinrichards That's a good question. I would use a linked entry instead, where you can set different permissions. I don't think you can set separate permissions if the OTP is embedded in another entry.

Best regards

@Daniel: I understand the concern. We discussed this internally and we agree it would be a good idea that only administrators can see the OTP seed. We will also make this change for 2021.3.

@justinrichards: With the change mentioned above, you will be able to enable "view password" on the entry, which will allow your users to view the password but not the OTP seed. If you want more granular control over the permissions, I suggest doing as Daniel mentioned and creating a separate OTP entry and linking to it.

Regards,

I wouldn't even let an administrator account read the seed, but that's safer than leaving it open to every user by default!

Thanks! Daniel

Thanks all. I agree that at a minimum, hiding the seed to ONLY administrators makes sense. Looking forward to 2021.3

Any update on this feature availability?
This is becoming a larger issue as we use so many OTP codes now. We are currently having to create a separate OTP credential for each one and set override permissions to make it usable.

Hello,

According to the information I have found in the tickets that were opened with our Engineering Department, these features should be available in RDM 2022.x. We will update this thread when we will know the specific version it will be in.

Best regards,