Published, as it is a duplicate of T25227: Use token when logging out.

Change 341135 abandoned by markahershberger:
thumb.php should use the ImgAuthBeforeStream hook

I would rather do what @Anomie suggested, that is using PrivateTmp=true for php-fpm. I'll look into it.

Google Chrome includes a password generator (and manager) these days that they prompt a user to use any time a password field with no saved passwords is focused:

Change 505644 merged by jenkins-bot:
[mediawiki/core@master] Synchronize allowed attributes for <audio> with Parsoid/TimedMediaHandler

Change 505644 had a related patch set uploaded (by C. Scott Ananian; owner: C. Scott Ananian):
[mediawiki/core@master] Synchronize allowed attributes for <audio> with Parsoid/TimedMediaHandler

The minimum viable version is merged now, you need to set the policy to [ 'value' => ..., 'forceChange' => true ] and you will not be allowed to skip the password change screen on login. We should also add a grace period but as discussed above that's rather more complex.

Change 481819 merged by jenkins-bot:
[mediawiki/core@master] Add force option to password policy

Change 481819 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/core@master] Add force option to password policy

In T197136#4280122, @Bawolff wrote:

You would also have to be careful about the case where the right is just checked for asethic purposes (e.g. adding a link to the special page if the user has the right to do the action)

I imagine the minimum viable version would look something like this:

• Create a new $wgPasswordPolicyGracePeriod config setting that gives you how much time users have to change their password (maybe per user group? per policy check?). Or preferably reuse $wgPasswordExpireGrace which is more or less the same thing but for manually set password end-of-life.
• If the grace setting needs to be set per policy check, look it up in UserPasswordPolicy and hack it into the status (set the value to [ 'grace' => <time> ] or something); otherwise just check it in the caller (LocalPasswordPrimaryAuthenticationProvider and the CentralAuth equivalent should be the only ones that care).
• In LocalPasswordPrimaryAuthenticationProvider, when the password check fails with a non-fatal and there is a grace period, set the password expiration time (user_password_expires in core; CentralAuth has no equivalent and needs a schema change, short of some horrible hack to reuse gu_password_reset_expiration with gu_password_reset_key = NULL). If we reuse $wgPasswordExpireGrace, just set it to the current date, if there is a separate config value that's split by group or policy then calculate the end of the expiration period and set it to that.
• Replicate LocalPasswordPrimaryAuthenticationProvider's expiry check in CentralAuthPrimaryAuthenticationProvider.
• Add a big warning about the expiration period to the password change dialog.
• Probably add password expiration time lookup as a User method, add some hook for CentralAuth, and use that method to show a warning on the preferences page and maybe do more aggressive things like showing it on every page when there is very little time left.
• In LocalPasswordPrimaryAuthenticationProvider::getPasswordResetData and the CentralAuth equivalent, when the expiry check fails hard, do a password validity check and if that fails use it to modify the message so it's clearer to the user why they are required to change passwords.

In T151011#4808817, @Tgr wrote:

There are two types of good password generation:

1. A medium-length string of random uppercase/lowercase/numbers (say 12 or 16 characters), with easily confusable characters removed from the pool.
2. A long human-readable text of space-separated random dictionary words (probably 5 or 6 words), e.g. diceware.

I'm not sure the first is worth doing as the only sane way to use such passwords is a password manager and that can generate random passwords just fine. (Maybe there are less technical users who have problems with password managers and just write the passwords down, but those are better served by diceware style passwords anyway since words are easier to type.) OTOH it is very trivial to implement.

The second is good for people who need to memorize the password for some reason, or need to type it in often (ie. often log in on foreign machines). The best library I have seen for it is grempe/diceware (test page), which has support for ~20 languages (of course it would be fairly trivial to add more). Word lists are around 100K which is a bit large but they don't exactly make an effort to reduce the size, which could be done pretty easily.

I'm not sure how worthwhile this would be if we ever got a decent password strength meter deployed. Though digging through the history, that might be a big if.

There are two types of good password generation:

1. A medium-length string of random uppercase/lowercase/numbers (say 12 or 16 characters), with easily confusable characters removed from the pool.
2. A long human-readable text of space-separated random dictionary words (probably 5 or 6 words), e.g. diceware.