gernoth

Just wanted to pop this up to the front again, because in our team meeting lot of colleagues complain that they do not like the change to devolutions because of it is impossible to use devolutions on more than one computer with passkeys saved in windows hello.

Do you have any news when this will be on your roadmap?

Thanks alot!

looking forward for phase 2! (phase 2 which is TBD, will allow users to set multiple factors of the same type as well. (special shout out to our very patient users dual wielding Yubikeys))

I like the option to define a seperate Master password per vault. We use this to give our T0 Passwords a bit additional safety in addition to the user authentication with FIDO2.

But the logical step would be, instead of asking for a master password of the vault being able to enforce 2.d factor check (like passkey...) again when clicking on the vault where configured.

Thank you, error message is now correct!

We are using different Password vaults for different Tiering levels.

Source is dvls: We have set a password policy for every vault:

When adding a new credential entry in devolutions password manager, it does not show the correct policy set for the vault:

(yes, i know that clicking on the three dots - Generate from policy and selecting policy works, but when policy is shown on click into field it should be the correct one)

Thats extremly confusing for users, because they click on create a new password and get an error afterwards because the password does not match the password policy.

The error is even more confusing:

The user should get feedback why an error occured (for example password does not meet password policy), not just an error occured.(like when using a pwned password)

Thank you!

Hi @Luc Fauvel

thank you very much, real passwordless sign in would be nice too.

But at the moment Yubikey is only supported as TOTP, not as a physical safe for passkey. Would be nice if Yubikey woul also get real Passkey support, not only TOTP.

Thank you!

Thank you very much.

We are not using external identity providers like Microsoft Azure on purpose (because we do not want that our password safe gets exposed when a user in Azure gets hacked). So the devolution internal passkey is the only really secure way to separate password safe from working environment, and a second passkey is really missing here.

Great when it's on the roadmap, hopefully more on the short term than too long :-). Looking forward to it!

+1

but please also think about supporting more than one passkey per user when putting this on the roadmap