- add space char seperators and create groups of 4 chars
- use monospace font
- increase the size of the codes slightly
Bug: T150907
Change-Id: Idb99f48b2d9eae6acacca80be61203ca6404782c
Google authenticator uses a space character as a group seperator.
We can thus expect users to enter such a separator and we should not
fail on that. Might as well trim whitespace too, as that is another
oft occuring user input mistake, that should not affect functionality.
Bug: T150603
Change-Id: I7334ed5dfaf933e61831438e2f86aa979cf9f51b
It's not like people are going to do anything else here, so
autofocussing is allowed in this case (no accessibility problem)
and speeds up interaction.
Bug: T150861
Change-Id: I6b41cc763156b48d8e35fb6829f70f0eb01e5511
A link names OATH is based because:
1: It's an abbreviation
2: It's too technical
3: It looks too similar to the more well know abb. OAuth
Bug: T150602
Change-Id: Id687d4089d03135061de716231b84b83bd4c0d84
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
