RDM requires re-authentication to Hub even 2 times a day

Hi @RDMTinkerer

Thanks for reaching out, a few things I'd like to address here. First, the need to re-authenticate often is indeed not normal, not intended and not what users regularly experience unless the Inactivity log off feature is enabled (In Administration -> Authentication). I'll try to see if we can add some diagnostics to figure out what might be causing this re-authentication as I don't see what might be causing this issue on my end. Does this occur if you use the external Authentication browser mode?



Second, the password becomes requested due to how Devolutions Hub handles encryption. We use the password to perform a derivation which then allows us to perform our encryption schemes for Devolutions Hub. In order to use your yubikey for this decryption process instead of a password, you'll need to enable the "Store encryption key" option on your yubikey in https://portal.devolutions.com/security/key . Please note that your security key and browser need to support the PRF WebAuthn extension.



And lastly, if you were given offline permissions in the hub, you should be able to read entries offline as it falls into read-only mode. It is not currently planned to allow offline writes with Devolutions Hub, but that would fall more under a feature request.

Let us know if there's anything else,

Cheers,

Thank you for your response. I switched to the authentication browser mode from Embedded to External. I have no idea what that changes in terms of security, we'll see if it alleviates my issue. (By the way my view of that window is different than yours, perhaps you have a newer beta version with more features.)

Let me share a few lines of feedback from a customer perspective.

The security as implemented in Devolutions portal and RDM becomes strange and hard to manage. On one hand, you've implemented all the modern security features (passkeys and hardware security keys) for which big thank you, but on the other hand the defaults are unreasonable.

The passkeys (including Windows Hello) were meant by their inventors as a secure, unphishable replacement for passwords, read that correctly: replacement, not addition. Yet your defaults are to not trust them alone. You require this obsolete, weak factor, password. This is so strange. When I log in freshly to my Google or Microsoft account, it just needs the passkey, and believe me, I have secret and valuable stuff protected by that "mere" passkey, for example quite a big cloud services with databases, user data, key vaults etc. Of course I do recognize the value of RDM entries, and the need to protect them. I just think the protection is over-engineered in RDM by default without added security.

A few minutes ago I added a passkey, and the default setting is that it additionally requires a password (see the screenshot below). Please revisit that default, because it's confusing, and does not correspond to security best practices.

The "Store encryption key" setting - I have no idea what encryption key it is going to store. But it's also not trusted by default, both for Windows Hello and for hardware security key. Why?

I love your software, I'm the paying customer, and I want to continue using it. I have just one ask: don't try to be "more secure" than security best practices established in industry. It doesn't increase security, it just increases user frustration and amount of issues and errors.

Thank you for your feedback. I’ll try to address everything here.

First the external mode doesn’t change much in terms of security except that it uses the system default browser. This can solve issues with session persistence.

Although I agree with you that the default behaviour for a passkey should be passwordless. The reality is just as you are opening a forum topic for this, we would get double the amount if we set it as a default as a lot of our users want their yubikey to be a second factor and not a first.

In terms of the encryption storage not being activated by default, the issue is PRF is a fairly new addition to the WebAuthn spec and most authenticators do not support it. This prevents us from setting it as default.

Lastly, if you’d look at other no-knowledge credential managers, you would largely encounter the similar frustrations. No-knowledge encryption like we provide for Devolutions Hub can be frustrating for both the user and us. But it is a compromise between user experience and user privacy that we try to balance. None of our employees can see your passwords and no government can compel us to provide them as they are encrypted with keys that solely you own.

Does that mean we can’t improve things? Of course not and we appreciate users like you reaching out to us when things bother them. We’ll try to rectify what we can (especially the constant login prompts which shouldn’t happen and seem to be a session persistence bug).

Let us know if there’s anything else.

Cheers,

Thanks. I acknowledge the points you raised. In that case I ask you to implement simpler flows for users, for example: when adding a new passkey, place a checkbox (option) "require password as a second factor for this passkey" (or "do not require password as a second factor for this passkey") so that I am not expected to know/remember the default you imposed globally, or to worry that it will ask me for a password next time. I use dozens, if not hundreds of different services from various vendors, and I cannot remember every quirk of every service. It needs to be simple yet powerful.

As for the authentication change from Embedded to External, it today asked me to re-authenticate just once, via browser, but I did not have to enter or provide anything, it perhaps just used an existing cookie. Still, I'd like to be able to decide if I want to be nagged by this every so often.

Thank you,

Hi @RDMTinkerer

Thank you, I agree with your feedback, we'll change the flow to ask users for their preferred defaults upon passkey creation instead of having them go back to the security key page.

As for the browser prompting, this is the behavior I expected, I found a way to somewhat reproduce your situation, but the external mode allows you to keep working without having to enter your password which I'm sure is still irritating, but less than having to enter your password all the time.

We'll update this thread once the potential fix is deployed.

Cheers,

Thank you. As for the authentication, it asks me to reauth every day on average. I do not know how will it behave if I have to work offline for extended period of time, like I had numerous times already.

Thanks!