I wonder if something like that would make sense for MediaWiki?

Sounds like a good new feature (at least, if the user can turn it off). Especially for critical on-wiki accounts, like administrators, bureaucrats or stewards (e.g.) it would be a nice extension for the security feature set to get informed, when someone log in to the account.

put the one.way hashed username in a cookie with very long expiration

Its unclear to me if storing a cookie for a super long time would be ok with the privacy policy or not (Unless long <= 180 days, which is how long the current cookie is allegedly stored for. 180 days is probably long enough though).

So I guess if we want to support this in the scenario where a single computer is used by multiple users, we would have to include part of the hash in the cookie name, as well as having it as cookie value (Where hash = HMAC using a secret key, as well as current timestamp), so that we could have multiple cookies for different users who might want to login from the same machine. At the same time, we'd also want to make sure that we wouldn't accumulate a large number of cookies on a single machine (e.g. A public terminal might accumulate hundreds of kilobytes of users if it was used by many many people, and we didn't delete cookies)

In T107707#2138015, @Bawolff wrote:

Its unclear to me if storing a cookie for a super long time would be ok with the privacy policy or not (Unless long <= 180 days, which is how long the current cookie is allegedly stored for. 180 days is probably long enough though).

Since this bug is in the MediaWiki-User-login-and-signup project, which is for core things (as opposed to extensions), I'm guessing this proposed feature would then go in core, right? (Which makes sense and is generally speaking awesome, btw.) Just make sure there's a toggle for it or something; even if the WMF's privacy policy would force some additional restrictions on this, the same is not necessarily true for third-party sites using MediaWiki, and I'm sure many third-party sites would like this feature.

In T107707#2138020, @ashley wrote:

In T107707#2138015, @Bawolff wrote:

Its unclear to me if storing a cookie for a super long time would be ok with the privacy policy or not (Unless long <= 180 days, which is how long the current cookie is allegedly stored for. 180 days is probably long enough though).

Since this bug is in the MediaWiki-User-login-and-signup project, which is for core things (as opposed to extensions), I'm guessing this proposed feature would then go in core, right? (Which makes sense and is generally speaking awesome, btw.) Just make sure there's a toggle for it or something; even if the WMF's privacy policy would force some additional restrictions on this, the same is not necessarily true for third-party sites using MediaWiki, and I'm sure many third-party sites would like this feature.

I was actually intending to work on something somewhat along these lines, but as an extension (Mostly due to wanting echo integration). Regardless of the extension/non-extension state, I would want any solution to be useful to everyone - but WMF is one of the primary targets, so I would want to ensure the chosen solution works well in that context. That said, the more I look at our current cookies, the less that this seems to be an issue at all.

In T107707#2138015, @Bawolff wrote:

Its unclear to me if storing a cookie for a super long time would be ok with the privacy policy or not

The cookie FAQ and cookie statement would probably have to be updated (although they are inaccurate and incomplete anyway), but the actual policy doesn't seem to say anything specific about this.

(Unless long <= 180 days, which is how long the current cookie is allegedly stored for. 180 days is probably long enough though).

Authentication-related cookies are all stored for 30 days (except for the session cookies), but the policy allows for 180 days, presumably in anticipation of T68699. FWIW a bunch of fundraising-related cookies are stored for one year.

At the same time, we'd also want to make sure that we wouldn't accumulate a large number of cookies on a single machine (e.g. A public terminal might accumulate hundreds of kilobytes of users if it was used by many many people, and we didn't delete cookies)

The cookie would only be set if users click "remember me", which users at public terminals presumably don't. But it would indeed have to be handled somehow - maybe just delete all cookies, or the older ones, if there are more than N. That might be annoying for people using lots of socks, but that's a fringe use case.

Alternatively, machines could have a single unique identifying cookie and user-machine pairs could be stored in the database. That has some benefits like enabling a "what machines have I recently logged in from?" security panel that most modern identity providers have, and ability to deauthorize specific devices, but it would also mean slightly more loss of privacy.

Speaking as someone who has recently run into about a dozen different sites sending me these warnings when I logged in (a) on a new tablet and (b) on an old machine using a different ISP... these were such a royal pain in the neck (in several cases I was required to "verify" my account if I wanted to use it) it resulted in my simply not bothering to log into some of those sites again.

Cookie-based security features are rather disturbing - I'd much rather the system encourage users to regularly wipe cookies than making features that enable poor security practices.

In T107707#2138134, @Risker wrote:

Speaking as someone who has recently run into about a dozen different sites sending me these warnings when I logged in (a) on a new tablet and (b) on an old machine using a different ISP... these were such a royal pain in the neck (in several cases I was required to "verify" my account if I wanted to use it) it resulted in my simply not bothering to log into some of those sites again.

False positives seem a lot worse than false negative for this type of system. Im really starting to think the best solution would be to do both cookie and pseudo-subnet based checks

@Bawolff has create an extension, LoginNotify, which handles this. I'm reviewing the extension this week.

The task description says -

if it's not there, and the user requested alerts, send an email with the IP and other details of the login.

To clarify, we aren't currently doing this in the LoginNotify extension. We can, but since most people don't have an associated email ID, we are wary of enabling them for now. We asked about this as part of the extension announcement but nobody brought it up.

The announcement says

This extension does not give you notifications when somebody successfully logs into your account from an unknown device or IP. It is technically possible to generate those, but if somebody else has logged in, they could just as easily see those notifications and do a password reset (which the notification encourages you to do). The ideal way to handle this is to issue email notifications for this case, but since most Wikipedia accounts do not have emails associated with them, this wouldn't be useful to majority of the users. So for the time being, we have settled for not issuing these notifications.

That reasoning does not make sense to me. High-value accounts (functionaries etc) almost certainly have an email address enabled, most power users do have an email address set, so most of the people who would actually get targeted do get a benefit from such warnings (unlike failed login notifications which have very limited practical value).

Also, an attacker does not gain anything from doing a password reset. They could change the email address but then the real owner at least gets warned.

In T107707#3267312, @Tgr wrote:

The announcement says

This extension does not give you notifications when somebody successfully logs into your account from an unknown device or IP. It is technically possible to generate those, but if somebody else has logged in, they could just as easily see those notifications and do a password reset (which the notification encourages you to do). The ideal way to handle this is to issue email notifications for this case, but since most Wikipedia accounts do not have emails associated with them, this wouldn't be useful to majority of the users. So for the time being, we have settled for not issuing these notifications.

That reasoning does not make sense to me. High-value accounts (functionaries etc) almost certainly have an email address enabled, most power users do have an email address set, so most of the people who would actually get targeted do get a benefit from such warnings (unlike failed login notifications which have very limited practical value).

Also, an attacker does not gain anything from doing a password reset. They could change the email address but then the real owner at least gets warned.

Apologies, I somehow missed this. I'll let @DannyH and @kaldari speak to this though.

@Tgr: Good points. We discussed moving forward with notifications for successful logins today, and I think it's a reasonable idea. (We were mainly trying to limit the scope to make sure the extension actually gets deployed.) I think we just need to flesh out the specifics for that feature a bit more, but it's doable.

Change 362323 had a related patch set uploaded (by Niharika29; owner: Niharika29):
[operations/mediawiki-config@master] Config changes for LoginNotify

https://gerrit.wikimedia.org/r/362323

@Niharika: Should be no blockers now. Please schedule this for SWAT deployment.

In T107707#3423365, @kaldari wrote:

@Niharika: Should be no blockers now. Please schedule this for SWAT deployment.

Scheduled for Tuesday evening SWAT.

Change 362323 merged by jenkins-bot:
[operations/mediawiki-config@master] Config changes for LoginNotify

https://gerrit.wikimedia.org/r/362323

Mentioned in SAL (#wikimedia-operations) [2017-07-11T23:25:18Z] <dereckson@tin> Synchronized wmf-config/CommonSettings.php: Config changes for LoginNotify (T107707) (duration: 00m 47s)