Login alert when user logs in from new machine
Closed, ResolvedPublic5 Story Points

Description

Create an opt-in email notification when a user logs in for a new device. This is for admins and active editors who are worried about getting hacked.

The notification is off by default, opt-in under the Notifications tab.

Definition of "new device" is the same as LoginNotify. There's a cookie per device, which lasts for 90 days since the last time you logged in with that device.

Email:

Someone (probably you) recently logged in to your account from a new device. If this was you, then you can disregard this message. If it wasn't you, then it's recommended that you change your password, and check your account activity.

Help information: https://mediawiki.org/wiki/Help:Login_notifications?markasread=60

Change password: http://core.local/index.php/Special:ChangePassword


original ticket:

Most large sites (Facebook, Google etc.) offer some kind of alert when someone logs in to an account from a new machine - it's a good way of protecting against account theft:



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

  • put the one.way hashed username in a cookie with very long expiration
  • after a successful login check for the presence of the cookie
  • if it's there, update the expiration date
  • if it's not there, and the user requested alerts, send an email with the IP and other details of the login.
Tgr created this task.Aug 2 2015, 7:11 PM
Tgr updated the task description. (Show Details)
Tgr raised the priority of this task from to Needs Triage.
Tgr added a subscriber: Tgr.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 2 2015, 7:11 PM
ashley added a subscriber: ashley.Aug 2 2015, 7:47 PM

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.

Tgr updated the task description. (Show Details)Sep 6 2015, 6:14 AM
Tgr set Security to None.
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptDec 15 2015, 6:24 PM

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)

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.

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.

Tgr added a comment.EditedMar 21 2016, 1:06 AM

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.

Risker added a subscriber: Risker.Mar 21 2016, 3:30 AM

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.

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

Reedy awarded a token.Nov 12 2016, 5:24 PM
Reedy added a subscriber: Reedy.
dpatrick added a parent task: Restricted Task.Nov 22 2016, 10:23 PM
Bawolff claimed this task.Nov 22 2016, 10:24 PM

I worked on this as part of LoginNotify extension.

See T140167 for more details.

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

Bawolff removed Bawolff as the assignee of this task.May 16 2017, 8:41 AM
Bawolff added a project: Community-Tech.

unassigning from self. Community-tech has taken over working on this extension.

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.

TheDJ added a subscriber: TheDJ.May 16 2017, 11:07 AM
Tgr added a comment.May 16 2017, 12:21 PM

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.

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.

DannyH updated the task description. (Show Details)Jun 13 2017, 10:56 PM
kaldari triaged this task as High priority.Jun 13 2017, 11:41 PM
kaldari set the point value for this task to 5.
DannyH updated the task description. (Show Details)Jun 15 2017, 5:59 PM
DannyH updated the task description. (Show Details)Jun 15 2017, 6:02 PM
Niharika claimed this task.Jun 27 2017, 8:42 PM
Niharika moved this task from Ready to In Development on the Community-Tech-Sprint board.

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.

@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)

Niharika closed this task as Resolved.Jul 12 2017, 7:40 PM

Here's what the HTML email looks like:

The preference is off by default for all.