Password policy checks that fail and have `suggestChangeOnLogin` set to true will
prompt for a password change on login.
Below are some rules that apply to this setting in different scenarios:
- If only one policy fails and has `suggestChangeOnLogin = false`, a password change will
not be requested
- If more than one policy fails and one or more have `suggestChangeOnLogin` set to true`,
a password change will be requested
- If `forceChange` is present in any of the failing policies, `suggestChangeOnLogin` value
will be ignored and password change will be enforced
- if $wgInvalidPasswordReset is set to false `suggestChangeOnLogin` is ignored
IMPORTANT**
Before this patch, suggesting a password change was the default behavior (depending on
$wgInvalidPasswordReset), which means that the necessary changes to $wgPasswordPolicy
need to be in place before this patch is merged and gets to production.
Bug: T211621
Change-Id: I7a4a0a06273fa4e8bd0da3dac54cf5a1b78bb3fd
So far, our key derivation code assumed that it has control over
the salt used by the derivation routines, however I want to add Argon2
support and it doesn't work this way: password_hash() generates the
salt itself, and the only way to verify a password is by using
password_verify(). Current way the things are done doesn't support it
because it relies on the result of password hashing with parameters we
provide to be deterministic.
Therefore, I'm deprecating Password::equals(), as well as whole concept
of comparing Password objects - it's used only in tests anyway. It's
getting replaced with verify() that only accepts password strings.
Uses of old function are fixed with exception of a few calls in tests
that will be addressed in my Argon2 patch.
Change-Id: I2b2be9a422ee0f773490eac316ad81505c3f8571
This is meant for private wikis where the list of users may
be secret. It is only meant to prevent trivial enumeration
of usernames. It is not designed to prevent enumeration
via timing attacks.
Bug: T134100
Change-Id: I7afaa955a4b393ef00b11e420709bd62b84fbc71
When the local password provider is in login-only mode, it should
disable itself as soon as some other primary provider is enabled.
It's impossible to tell whether that is the case though, so err in
the safer direction.
Change-Id: Ie77a9cc6d8f06aa52a893e753d9971e30b0f55e5
I found this confusing when reading the code. This should have
identical logic but slightly clearer.
Change-Id: I4918c29bd5dca3642de7bb60219fc246299d952d
An A-type hash is an unsalted hash. A B-type hash is a salted hash of
the form md5(salt "-" md5(password)). So it's not correct to have an
A-type hash with a salt. User::comparePasswords() and
CentralAuthUser::getPasswordFromString() already get this right, they
generate :B: prefixes for legacy salted hashes where the salt is not
specified in the database.
Change-Id: Icb809274f9f63641e54daf98332a5646fd58b550
This implements the AuthManager class and its needed interfaces and
subclasses, and integrates them into the backend portion of MediaWiki.
Integration with frontend portions of MediaWiki (e.g. ApiLogin,
Special:Login) is left for a followup.
Bug: T91699
Bug: T71589
Bug: T111299
Co-Authored-By: Gergő Tisza <gtisza@wikimedia.org>
Change-Id: If89d24838e326fe25fe867d02181eebcfbb0e196
