Configure "ActionFilteredLogs" in extension.json to allow filtering
the oath log by its two actions, verify ("checking" in the UI) and
disable-other.
== Test plan ==
* Enable 2FA on your administrator account, use Special:VerifyOATHForUser
and Special:VerifyOATHForUser to generate two log entries.
* Visit Special:Log/oath and use the new action selector, testing each
state to verify the correct set of logs are shown.
* Screenshots showing this testing are posted at T310487#7999991.
Bug: T310487
Change-Id: I10632c86689e330b21b44a096b098436ebe47e3e
Notify users when 2FA is disabled on their account in case something was
fishy about it. This notification is a "system" notification that will
be displayed in the web UI and sent over email. It can't be opted out of
as a preference.
The notification links to Special:Preferences, where users can see their
2FA status and re-enable it if they want. A secondary help link goes to
[[mw:Help:Two-factor authentication]], but can be overridden by
adjusting the "oathauth-notifications-disable-helplink" message. The
notification text is different based on whether the user disabled 2FA on
their own, or an admin used the special page or a maint script to do it.
On Wikimedia wikis, we'll use the WikimediaMessages extension to
customize the messages.
The Echo (Notifications) extension is not required, this will gracefully
do nothing if it's not enabled.
Bug: T210075
Bug: T210963
Change-Id: I99077ea082b8483cc4fd77573a0d00fa98201f15
Users in groups listed in $wgOATHRequiredForGroups (default none) must
have two-factor authentication enabled otherwise their membership in
those groups will be disabled. This is done using the
UserEffectiveGroups hook, which allows dynamically adding or removing
user groups.
If a user doesn't have 2FA enabled, it will appear to them as if they
aren't a member of the group at all. Special:Preferences will show which
groups are disabled. In the future it would be good to have a hook into
PermissionsError to show this as well. The UserGetRights hook is used to
ensure the user still has the "oathauth-enable" user right in case it
was only granted to them as part of the user group they are disabled
from.
On the outside, Special:ListUsers will still show the user as a member
of the group. The API list=users&prop=groups|groupmemberships will show
inconsistent informaiton, groups will remove disabled groups while
groupmemberships will not.
This functionality was somewhat already available with
$wgOATHExclusiveRights, except that implementation has flaws outlined at
T150562#6078263 and haven't been resolved in I69af6a58e4 for over a year
now. If this works out, it's expected that will be deprecated/removed.
Bug: T150562
Change-Id: I07ebddafc6f2233ccec216fa8ac6e996553499fb
- When explictly disabling a method
- When method is implicity disabled if user switches to another method
Bug: T232008
Change-Id: I97a96ca7c1935ecb3a81aea35f607b8ff9f8817d
Help messages for 2FA in general and for TOTP module are taken from Wikipedia.
Those could probably be improved, any suggestions are welcome
Bug: T218214
Bug: T226056
Change-Id: Ifc81a3c0e1adc9f6d0d49e7eee086714fc2c0f81
This is the message that displays right after successfully
introducing username and password. It appears standalone in
a box and misses the final dot.
Change-Id: I7911bb0f9c2ab30756ff53d96d6bda3df6e822b0
If I understand correctly, the messages is about the
"two-factor authentication status of users", so it should
be written as possessive.
Change-Id: I084029d6cdf6288b904f22e9ed2e098a42dbefb0
It's better that we add for when someone enables or disables for self too
But that can be done in a follow-up patch
Bug: T180896
Change-Id: Ic173ebb7e39d22e40fea23c2b906d246adef1e05
Validating with a scratch code is probably a "giant trap that newbies
could fall into".
Bug: T150824
Change-Id: I5710b151d7682e4cdb0b6a692f7b2c108f051caf
Rename this key from failedtovalidateoauth to failedtovalidateoath
as it has nothing to do with OAuth
Bug: T151536
Change-Id: Ib34ef3dbdef8eda515748140960ef240e4990044
To make clear from the message name which module it belongs to, two
example messages should be renamed.
Change-Id: Idd329e77d5c7082eb8097309fb89f82c7a37cf68
Desktop programs for TOTP authentication also exist, so lets replace
'mobile app' to more generic 'authentication device' to cover all of
them. Improvements on the wording are welcome.
Change-Id: Id19ac30dc7ac36616b8e00b1b4c9e95eec8afc06
Extend the token validation failure checks introduced in I4884f6e to the
other interactions where OATHAuthKey::verifyToken is used.
Depends-On: Ia3add8bbbab0307f036e9b77e752c382da3a0d04
Change-Id: Icbe5cdf561c683dc971a099d61cedff311b26b43
Add a new internal action=oathvalidate Action API module that can be
used to validate an OATH token collected from a user. Using the module
requires the 'oathauth-api-all' permission introduced in I4884f6e.
Attempts to call the action for a given user are rate limited to only
allow 10 failures per minute using the new 'badoath' key.
The check is primarily useful as an internal network service in an
environment where MediaWiki and other applications are sharing the same
backing authentication store (e.g. LDAP) and the non-MediaWiki
applications would like to respect the OATH protections enabled on the
MediaWiki install.
Complete usage in an LDAP shared auth environment would look something
like:
* Authenticate a user with the LDAP server via auth-bind
* Call action=query&meta=oath as a privileged user to check for OATH
protection.
* If OATH is active for the account, prompt the user for their current
OATH token.
* Call action=oathvalidate as a privileged user to validate the token.
* If validation succeeds, complete authentication.
* If validation fails, do not authenticate the user.
Bug: T144712
Change-Id: I1b18d9f3b99364fc47c760bdfc2047c1cbb5c04a
Add a new internal action=query&meta=oath Action API module that can be
used to check for OATH protection on a given user account. Using the
module requires a new 'oathauth-api-all' permission which is not granted
to any group by default. The permission is also added to the new
'oath' grant so that it can be used via OAuth and bot passwords.
Use of this API is security sensitive and should not be granted lightly.
Configuring a special 'oathauth' user group to grant the needed
'oathauth-api-all' permission is recommended.
This check is primarily useful as an internal network service in an
environment where MediaWiki and other applications are sharing the same
backing authentication store (e.g. LDAP) and the non-MediaWiki
applications would like to respect the OATH protections enabled on the
MediaWiki install.
Bug: T144712
Change-Id: I4884f6efdfa42db82c25eadb70c7aefa98c370e9
Rather than have an extraneous form on the login page,
move the token input to a separate page. The actual
logic for logging in is identical, the only difference
is that the token is added to the form data on a second
page request.
Bug: 53195
Change-Id: I39859cc59f1811de42b72f6167d332ea48812f97
Make new right oathauth-enable that the user must have to enable two
factor authentication (disabling and logging in, of course, are still
allowed).
Bug: T100376
Change-Id: I18d43f8b2cf2c2ce9c2309a43961686498b5c999
Made new class ProxySpecialPage, which acts as a
proxy object to another SpecialPage object that is
determined based on context information other than
the title.
Then Special:OATH has been split into two separate
special page classes (both FormSpecialPages using
HTMLForm) that are routed to by a ProxySpecialPage
object.
In addition, the form for enabling two-factor auth
has been refactored into vform style, with some
better instructions on how to enable two-factor
authentication.
Change-Id: Ib9117cbc9d7f044de9607db81a157e1b472b5ec0
