This makes it possible to check from another extension whether the
user has strong login security, without depending on internals
which can change at any time.
(The TwoFactorEnabled hook was intended for something like this
but it operates on $wgUser which makes it useless for logins.)
Change-Id: Ie15c45c9b29de0a0f926c2467808ca144f05e866
It's only used as a dependency for one module, so it doesn't really make
sense to have it as a separate module.
Change-Id: I0936073358e98d236ce9440d92873a2ea3851e60
The issuer name is an optional but important feature that allows
the user to differentiate between different accounts used in the
same authenticator app. While we currently use a prefix in the
user account name, declaring an issuer makes it easier for the
user to differentiate.
Bug: T150596
Change-Id: I741dd671e79e0326dfe97bdaaf63b3997960d115
If the user has a key set but not the oathauth-enable userright, still
show the link to Special:OATH so they can manage it.
This can occur when only restricted groups are allowed to use OATHAuth,
but the user database is shared across multiple wikis.
Bug: T150584
Change-Id: I2db8b47051b0857538e668d233f5cb8586c328a1
Created patch files for other database types.
Note that some types, such as Oracle, are
not guaranteed to work, since not even MW
core works with them yet anyway.
Bug: T67658
Change-Id: Ie9ce8a4d1140d16017c1aa83865f79d8b0986528
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
* Spelling in OATHAuthHooks::onRegistration comment
* Remove incorrect comment for OATHAuth::__construct
* Spelling in TOTPAuthenticationRequest class phpdoc
Change-Id: Iaf670a1b86e82b4684489371c8152b8055bff90e
