Replies: 3 comments
-
Hi @ghalse Without going into details. As for setting a limitation on the lifespan of the various elements available in MFA. we have to think about it, here we are in the details. For the MFA suspension cookie, it exists if you activate the function, and of course, this cookie is already encrypted (AES, AES ECDH_P256) regards redhook |
Beta Was this translation helpful? Give feedback.
-
Hi @redhook62 Thanks for the response. I realise I violated the first rule of opening issues here -- doing so based on an old version. I've now upgraded our install and see the option you're referring to. However, it's really not clear how that's supposed to work, since I see no options within the user interface to allow users to pause MFA? I've looked through the documentation, and it doesn't offer any insights either. However, if it allows users to pause MFA on a per-browser/per-device basis, then that is really already the functionality I was getting at. Thanks |
Beta Was this translation helpful? Give feedback.
-
Hi @ghalse The encrypted cookie is valid for full days. You can safelly delete this cookie. regards |
Beta Was this translation helpful? Give feedback.
-
Hi
I wanted to (re-)ask about the possibility of adding "Remember this browser" / "Trust this device" functionality to limit the number of times users are prompted for MFA on frequently used devices. I see that there was some discussion about this in 2020 in #119, where you asked for discussion/proposals. However, it occurs to me the problem can be simplified relative to what's in that original enhancement request.
Rather than remembering devices indefinitely, they could be remembered for a finite (configurable) time. Microsoft's Azure MFA currently limits this to 90 days, but smaller values like 30 days seem common too. For people who authenticate frequently in different browser sessions, even a couple of days might be useful. The implication is that trusted devices automatically go stale after a period, obviating some maintenance requirements. By making the timeframe configurable, you allow admins to make their own risk decisions (a value of 0 days could mean disabling the functionality).
Similarly, there may be no need to have a database of every device server side. Rather than revoking trust individually, users could simply revoke all trusted devices and re-trust on next login. I think that simplifies the storage requirements.
With those two refinements, this could be implemented using a cookie or local storage in the browser. The MFA server could encrypt a cookie value containing an expiry timestamp and a per-user trusted token, and store the encrypted value in the browser. Subsequent logins then trust cookies that are both properly decrypted, have the right token, and are still valid. All that'd be required is a encryption secret for the token (which probably already exists in the RSA master key?) and a per-user token. Trust for all devices can then be revoked by simply changing/deleting the token.
I'm aware of the pass-the-cookie type attacks, but those can be mitigated by allowing concerned admins to disable the functionality (or better yet, specifically enable it). They're also probably less of a risk than email tokens being intercepted or forwarded. For many use cases, easier-to-use MFA that's actually used might be better than users trying to actively bypass it.
Thanks,
Beta Was this translation helpful? Give feedback.
All reactions