Page MenuHomePhabricator

Weird behavior for 2FA
Closed, InvalidPublic

Description

For a period it was possible to enable 2FA, and then later reset the password without 2FA being invoked. I can't remember if the 2FA was disabled afterwards. I doublechecked the other day (25 nov 2018), and this seems to fixed, but someone else should check.

I logged out, then requested a password reset, and afterwards was logged inn.

Event Timeline

@jeblad: I don't know what exactly is asked for in this task and what exactly is "weird". Please see + follow https://www.mediawiki.org/wiki/How_to_report_a_bug
"this seems to fixed" means that it seems not possible anymore to reset the password without confirming via 2FA?
Which website is this about? Some Wikimedia SUL wiki, or wikitech?

You may replace the title with whatever works for you.

The mediawiki extension OATHAuth is in use on several wikis, and I observed this on Meta as I recall (?), but later I could not reproduce on Meta. (I wonder if I saw this behavior the first time at nowiki while running pywikibot. I had to turn 2FA off to run the bot. Use of 2FA was previously turned on at sewiki, a very small wiki.)

I observed the behavior, I reported the behavior, and now it seems I can't reproduce it anymore. If someone says it does not happen, or never happen, or even that the report is invalid, then it is fine with me. I only report this as an observed issue.
Bugs that disappears without any clear reason usually comes from an yet unexplained logical error. That usually means it is a serious issue *somewhere* in the code.

Perhaps I'll look into the code, but it won't be now. (It should work with FIDO keys.)

(Just an addition: A FIDO key does not create a two-factor system by itself, it is only a convenient way to provide a proof of "what you have".)

You may replace the title with whatever works for you.

That first requires a task description that allows others to understand what you think is (or was) a problem.

This is pretty well-known, but here it comes.

Resetting the password (what you know) on a two-factor enabled account without the second factor being triggered leads to a one-factor system. A system isn't a two-factor system because you have an app on a cell phone, it is two-factor because you must use two separate systems to log in or change your credentials. Those separate systems should ideally use two of the three "what you know", "what you have", and "what you are".

A proper implementation of a two-factor system is implemented as a three-factor system where you only must use two of those factors. That is why there are scratch codes. It is one of those additional factors (an additional "what you have").

If you forget one factor, like you loose your cell phone, then you must use some other factor to stay secure. You simply use a scratch code. You could in theory send a new token on some other communication channel, but if that is an insecure ad-hoc channel then you loose a factor. Email and SMS have weak security, while scratch codes are pretty strong. You must keep the scratch codes (what you have) secure, otherwise you loose a factor. An ultimate factor could be to identify yourself (what you are), but as long as there are no previous identification, the identification fails.

A two-factor system that allows resetting or changing any credentials without requiring two separate factors are pretty weird, as it would then be a one-factor system. In this case I previously found a situation where no valid credential was necessary except being able to observe the users email system. That is a very weak clause. The system as I currently find it require the cell phone and still only being able to observe the users email system. That is still a pretty weak system, but perhaps acceptable.

Email and SMS are not considered secure channels, they are just slightly hard to get access to. Compare this to resetting a normal account and you see how very weak the security already are. Due to this I did not expect anyone would fix the described problem, thus and so far I still not believe it will be fixed.

A proper fix of the reset password problem is to view it as a one-factor problem, thus to reset a password you need an additional factor, so use scratch codes. If someone does not have scratch codes, that is the user has not ticked a box for downloading the scratch codes for safe storage (probably also verified the existence of the scratch codes a few days later), then and only then should the system back down to using email.

Never mind, this will not be fixed.