The documentation on 2 Factor Authentication says this:
If you lose access to your 2-factor authentication (such as by losing your phone or performing a factory reset) and you do cannot log in, you will not be able to access your account and will need to contact an instance admin to remove 2-factor authentication from your account.
However the admin of the site I鈥檓 on is having some trouble actually doing that. Is that process to reset 2FA documented somewhere?
2FA hasn鈥檛 been working since an upgrade last night for myself and at least one other user. Neither Admin nor either of us know what is causing this at present.
master (If you're a user, don't worry about this).I am on this instance as well and here is detailed documentation on the issue with a video showing what is going on from the client side: http://dave.sobr.org/html/BugReportCantloginto-1493163694.html
Dave鈥檚 much better documentation matches my experience precisely. This all kicked off last night I believe after the Admin upgraded to 1.2.2
I'm the admin, yes I upgraded to 1.2.2 and I concur it broke several user's 2FA.
Is there a way for a non-db admin type of guy to remove 2FA from the accounts affected?
Can you get us a snip of the production logs around the time the error occurs - showing the request coming in, and ideally what is failing?
If you can set log level to "debug" to capture that, that'd be great.
@mjankowski Would OTP_SECRET getting clobbered during an upgrade result in this type of behaviour?
I got pinged asking how I remove 2FA from users, so here's how for any instance admins that need it:
sudo docker-compose run --rm db psql --host=db --username=postgres (NOT localhost! That makes it try to use the FIFO pipe which isn't created by the Docker setup.) On a non-Docker setup this is probably just sudo psql.UPDATE users SET otp_required_for_login=false WHERE email='[email protected]';(I got a direct link to this issue, so sorry if this reply is not particularly pertinent to the issue; I'd imagine this will be the first thing instance admins find if they're trying to solve this problem though, and this workaround is fine in the meantime.)
On this issue specifically, I run the Docker setup and every user whose 2FA I've corrected has been the result of user error due to the lack of verification in older Mastodon versions. I've never had 2FA mysteriously stop working due to an upgrade or otherwise.
EDIT: I just updated my instance to v1.2.2 and 2FA still works.
I rolled a mastodon server instance and confirmed that changing the OTP_SECRET value in the configuration file does indeed produce a 500 error for users trying to log in that had previously setup 2-factor auth before the change. I'm not sure if that's what is happening in this case, so I'll check with @adamc199 .
@unascribed In case an instance had it's OTP_SECRET changed or corrupted and the original value could not be recovered, would this be an acceptable reset of all 2fa users on the instance without doing any damage:
UPDATE users SET otp_required_for_login=false WHERE otp_required_for_login=true;
Yes, that update statement would work.
I opened a PR which would change the way this case is handled and instead of an app error, present with a failed 2FA message (the same as if there were an error w/ the code). This seems better than an error, at least.
Might be useful to separately document this situation for admins to understand the implications of rotating their secret?
Excellent fix: UPDATE users SET otp_required_for_login=false WHERE otp_required_for_login=true;
This appears to have done the trick.
This is very much appreciated.