Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
Once #2239973: Deploy two-factor-authentication on drupal.org is deployed. We will need a policy for removing tfa if a user gets locked out.
For accounts that have certain roles, I feel this should required a trusted user to confirm that the other user is who they say they are. This would be via phone call etc.
This issue is to track the communities ideas around this.
Comments
Comment #1
drummComment #2
coltraneHere's some policy ideas but I also want to note that separately we should discuss the actual methods for reset/access grant (basically: disable their TFA vs pass along a token).
If a user contacts for support or administrative assistance because they're locked out (and not via flood block) I see two courses of action. This assumes there is some basic role on the site that is allowed to set up TFA but is not required to have set it up to authenticate (TFA Basic provides role enforcement). For example, on drupal.org I expect the community role to eventually be allowed to set up TFA but not be required to do so to log in.
1. To allow the user to immediately log in, remove any admin-roles that are set for requiring TFA setup -- effectively removing any special access the user has under the assumption that if an attacker is controlling the account they can't do much without that admin-like role.
Then later, to re-grant the user their admin-like roles would require carrying out some stronger form of identity verification or vouching.
2. Leave admin-roles in place and first carry out a stronger form of identity verification. Once confirmed re-grant access following yet-to-be-determined methods.
I think option 2 is better but it's possibly more time sensitive and intensive on support channels.
Verifying identity
As @mlhess suggests, ideally some new communication channel should be used to validate the situation, such as a known phone number or secondary email account (on different host). Calling the person up and saying something like "Hi, we received a notice from your account that you are locked out of the site, can you confirm that is the case and repeat your main email address you currently have set with us?"
Or, rely on a separate and trusted individual to vouch for the person and their situation. For example, if Dries were locked out, a communication from Angie (ideally on a secure channel) affirming the situation and that the person isn't hacked could be considered enough to reset access.
Comment #3
lizzjoyI think that it would be best to talk out these options. Since DrupalCon is just next week, I would like to see if we can sort this out then. Implementing a phone support system for this would take time and I think our current setup for using zendesk + help@drupal.org for account recovery has been working well so far.
I do like the idea of asking for information up front that we'd use to verify identity beyond just one email address (like Who is your trusted individual?). When someone wants to recover a long lost account they cannot always remember the email they provided to us when setting up their account. A workaround to resolve that would be nice.
Comment #4
greggles@lizzjoy - I agree the current process is working well. This is about an additional protection for accounts that ensures the two-factor-authentication protection is not weakened and yet can be removed when necessary.
Comment #5
coltraneFor general locked-out users (those without admin-like roles) I think it's acceptable to relay trust to their email provider. If locked out, these people could initiate a TFA reset process where they're emailed a link that once clicked (and after verifying correct password) simply disables TFA for their account. This process could be limited to certain users (roles or code-based).
Comment #6
hestenetTo summarize our current thinking on a policy:
For users with community privileges or below:
The user does not know their password either
^^ Does that negate the value of two-factor on these accounts? Essentially - knowledge of and access to the email address would be sufficient to disable TFA for the users without elevated privileges.... we should think about that carefully.
For users with more privileged roles than community:
Again^^ We should review this to see if we consider it strong enough to reset TFA (and whether this is vulnerable to social engineering since we're posting this policy publicly).
Also, no plan survives first contact with the enemy, so we may need to be flexible enough to tweak this policy as we start seeing these support requests in the wild.
Comment #7
gregglesIf you know their email address it's simple to achieve this: open a browser that is not logged into the site, go to /user/password, enter their email...done.
I think your statement of the plan and your concerns are accurate. I would add something about "encourage the person to get their Recovery codes and put them in a safe place".
Ultimately we can't guarantee that we protect all accounts. But...we can at least protect accounts that have the ability to do more advanced things.
Some other pieces of information you could use to verify someone:
* the users.init column in the database. It is the email address used to sign up for the account. It is only visible if you have database access to the site. There's only 36,441 people who have changed it from their current email address, but I bet most of those 36,441 have a high overlap with the set of people who have advanced roles.
* the additional emails on an account provide another question: there are 12516 accounts that have an email in multiple_emails that is not their primary email account.
Comment #8
Leeteq CreditAttribution: Leeteq commentedHow about enabling password reset links to also be sent to (any of) the extra email addresses?
(This has been requested on several occasions in separate feature requests both for core and for such extra modules.)
We can then for example require that in the case of disabling TFA, the user is required to enter one of the extra email addresses, and will only get such TFA-disabling links sent there, and not to the default email. This means that the user needs to know one extra piece of information to disable TFA.
Could that work as a sufficient extra layer of security?
When a user is logged in here at D.o., and uses the contact form to connect with another user, his main d.o. email is suggested as the "from" / reply-to email, which if not changed, reveals the email for that account to the third party. In certain identity-theft scenarios, it is possible that a person who want to hi-jack another's account may get to know the associated email in question, especially if this happens on a public Wi-fi network, say for example during a DrupalCon...
A major point here is to make this both ('sufficiently') secure and fully manageable by each user without needing manual assistance from support people at d.o.
The Trusted users solution is a good idea that serves a part of the community.
The idea of letting trusted users vouch for others for administrator-like roles is good, and should also be considered, although those people are also often well connected via IRC etc. and many or most may already have ways to get verifiable assistance from d.o. through other such channels. That part does not solve this problem for normal users, though.
Obviously, using (one of) the extra email address(es) for this may complicate things for some users who have forgotten which emails they have registered, but what if we made it an awareness issue related to TFA: inform all about just that fact when they are configuring their TFA settings the first time?
Better solution, (related, but more of a new feature request for a separate issue)..:
A more proper workaround for this would be to change the way TFA works so that we can add as many extra TFA's as we like to each account; a couple of smartphones, a Yubikey TOTP or two, more than one Twilio, etc. Perhaps even a separate set of Recovery codes associated with specific added emails? The https://www.drupal.org/project/yubikey module lets each user enter more than one Yubikey so that if one is unavailable, another can be used. That way, if having any of the multiple factors available, one can log in.
Comment #9
Leeteq CreditAttribution: Leeteq commentedComment #10
greggles@lizzjoy @hestenet et. al. has this policy been used? Has resetting access been a problem in any way on d.o? I'm asking to see whether #2497389: Support self-service TFA reset when locked out should be worked on.
Comment #11
B_manThe method that @hestenet mentions above is pretty much how I have been handling these types of requests so far. Fortunately, very few have been from folks that have elevated privileges. For those with elevated privileges I always try to verify another piece of information about the account before removing TFA, and in the process of removing TFA strip elevated roles from the account. The hope being that this is enough time (several emails back and forth) for a potentially compromised to be noticed either by the account owner or someone else in contact with said person.
That said, we do have to field a steady stream of non elevated users submitting tickets to remove their TFA (on the order of 2-3 a day). It would be great if there was some sort of self service way for them to go about doing that.
Comment #12
mlhess CreditAttribution: mlhess as a volunteer commentedI am closing this issue as the policy issue is taken care of.