Is it possible to not require the account recovery key when recovering the account?

[danielvaknine]

Proposal

We suggest the possibility for admins of sites (and where applicable, admins of mother-site for a site containing multiple sub-sites) to disable the Account Recovery key function for some or preferably all users.

We also suggest increased focus on 2FA.

Motivation and context

Very few users remember to save the Account Recovery Key, especially in smaller organisations that rarely log in to the system (once every year, for example). This forces admins to send resets link to bypass the Account Recovery Key.

Instead, we suggest that passwords can be reseted without this Account Recovery Key, if admins decide that is what they want to do.

Increasing focus on 2FA: Currently, 2FA is a small checkbox while the Account Recovery Key is a large box in the settings. The user also gets information to save the Account Recovery Key when the account is first created, but no information about 2FA. We suggest that more focus is put on 2FA because this is much easier to use and probably safer than saving your Account Recovery Code on your desktop.

[evilaliv3]

Hello @danielvaknine

This is simply not doable and account recovery keys are necessary to recover the key in fact reports are encrypted with encryption keys specific for each user that are kept encrypted in three copies:

1. one copy is encrypted with the current user password; this copy is used when the user logs in;
2. one copy is encrypted with the account recovery key of the user; this copy is used by users that have lost their password as a personal method of recovery;
3. one copy is encrypted with the system escrow keys; this copy is manually unlocked when administrators operates on the system

we may evaluate to make it optional to enable option 2. but in my opinion it makes no sense since it means that the user to recover their account will have to always write to administrators.

I hope this helps the understanding.

[danielvaknine]

Hi @evilaliv3 , I understand what you're saying but that is exactly our point:

As it is today with the Account Recovery Key, users loose them very fast or don't even save them to begin with (even though we recommend this). Thinking of the small organisation with a limited number of reports, this makes sense since they use the platform maybe once a year or when a report eventually comes in.

Then, they have:

1. Forgot their password and
2. Lost their Account Recovery key.

This forces them to contact administrators to bypass the Account Recovery Key in order to set a new password.

The suggestion would be to enable administrators to disable option 2, hence making it possible for them to choose whether or not the Account Recovery Key is a good option for the organisation in question (probably with having it enabled as default).

(A partly unrelated note regards increased focus on 2FA. Disregarding the above, 2FA does not get the attention it deserves in relation with the Account Recovery Key.)

[danielvaknine]

Anyone with thoughts on this or experiencing similar issues?

[evilaliv3]

Daniel: let me say it differently: there is no way to enable users to recover their data alternatively to implement an account recovery key (that is a secondary key alternative to their password).

In other ways if you want encryption you need them.

Alternatively if you do not want to enable account recovery either the data is in plaintext, either the data is lost.

[danielvaknine]

OK, I understand. However we know many services that don't implement these kinds of keys and still encrypt (in a way that at least they themselves call highly secure and in accordance with iso 27001).

Thinking outside of the box – couldn't it be an option to link the Account Recovery Key to the 2FA instead? Currently when resetting your password you need:

1. Access to your email account
2. Your 2FA code
3. Your Account Recovery Code

This seems a bit excessive in our opinion, where 1) and 2) would still be a highly secure solution. Though, we still understand your concern regarding encryption and a secondary key for that.

We're simply conveying the thoughts of our clients and the struggles they come across. In 90% of cases, they need to contact us in order to reset their account without the Account Recovery Key, which forces us to verify their identity manually.

Appreciate you taking the time!

[evilaliv3]

1) decrypting with 2FA is not possible, the 2FA code is not a key. The TOTP secret (the one contained on the qr code) is of course in plaintext on the server in order to be used. If you think it helps during the recovery process we could not ask for 2FA but only for the account recovery key but that is necessary. 2) Regarding the systems that you mention I do not really think they exist but I think they just lie. But If you are aware of a known protocol that can make this please let me know. In my opinion they have just disk encryption when the disk is shut down or they have an online escrow key loaded into the system.

…

On Wed, Apr 3, 2024, 5:18 AM Visslan ***@***.***> wrote: OK, I understand. However we know many services that don't implement these kinds of keys and still encrypt (in a way that at least they themselves call highly secure and in accordance with iso 27001). Thinking outside of the box – couldn't it be an option to link the Account Recovery Key to the 2FA instead? Currently when resetting your password you need: 1. Access to your email account 2. Your 2FA code 3. Your Account Recovery Code This seems a bit excessive in our opinion, where 1) and 2) would still be a highly secure solution. Though, we still understand your concern regarding encryption and a secondary key for that. We're simply conveying the thoughts of our clients and the struggles they come across. In 90% of cases, they need to contact us in order to reset their account without the Account Recovery Key, which forces us to verify their identity manually. Appreciate you taking the time! — Reply to this email directly, view it on GitHub <#4016 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABU7SRY5GJZC6QI2BMCWDDY3NYKFAVCNFSM6AAAAABEHMPCYCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DSOJRGYYTQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[evilaliv3]

In my opinion the following edits could simplify; 1) We can remove 2FA when an account recovery key is used. I will apply this right away. 2) We can add a button "I do not have the account recovery key" and if clicked give a message to the user saying "the request has been sent to administrators"Then we could: send an email to the administrator and register on the system that the user is waiting for a password reset and enable users to log in and authorize the password reset viewing the list and authorizing one by one or all at once. @rglauco @larrykind: what do you think?

[rglauco]

i agree

[danielvaknine]

This seems like very good and well-needed improvements! Especially number 2) would be a very good improvement regarding user friendliness!

[danielvaknine]

Any updates on this?

[evilaliv3]

Not at the moment

[larrykind]

I generally don't agree to bypass security In favor of ease of use, anyway n.1 seems ok in my opinion.

Regarding point n.2, in my opinion it seems that user could be authorized to password reset without really identifiying himself to the administrator and using just username (or email).
So administrator can't verify if the user requesting the reset is really who he claims to be.
So finally, to identify the user, the user that lost the password and recovery code should insert for example a phone contact to be identified, if in doubt.
Thank you for considering it

[danielvaknine]

I agree with your thoughts. We always verify the user's identity. Leaving a phone number for the administrator would make that a lot easier!

[danielvaknine]

Hi, was any of this implemented or not? And is there anything we can do to help with the development?