@Magnus If the notifications are from a few wikis, you can turn this off in the Notification preferences. This feature was enabled by default for all wikis on the request of community members - see T174263.

Maybe this should be turned off for users with the bot flag?

I started getting these emails for Legobot today at 3pm PST, so the timing is different than Magnus, but same exact symptoms. Ideally we'd hold bots to higher security standards so I'd hope there's a different solution than just disabling the feature :/

@Niharika and I discussed this in #wikimedia-commtech. She pointed out that LoginNotify will treat an IP as "old" if there is data in CheckUser tables for that address. Data is added to CU upon account creation, edits, and log entries. So if a script logs in and doesn't make any edits, that IP is not considered to be old, and upon the next login will still be seen as new. LoginNotify normally sets a cookie in browsers for this so if the device is trusted it won't warn again, but at least my script doesn't retain any cookies so that feature doesn't work.

@Magnus are your bots using normal password login or OAuth? And have they been making edits or just logging in?

@Legoktm

Both bots use the Addwiki lib, not sure if that uses OAuth:
https://phabricator.wikimedia.org/project/profile/1490/

Both bots are making edits:
https://www.wikidata.org/wiki/Special:Contributions/Reinheitsgebot
https://www.wikidata.org/wiki/Special:Contributions/QuickStatementsBot

I also get a few "failed login" message for both.

@Magnus It seems it's only Wikidata you're getting notifications from? Could you turn them off in preferences?

Yes, ListeriaBot (which edits Wikipedia) does not cause those (so far), so only Wikidata.

And I would rather have someone fix this security-relevant feature than turn it off. If your anti-lock brakes make annoying noise, wouldn't you rather have them fixed than removed?

In T182867#3840388, @Magnus wrote:

Yes, ListeriaBot (which edits Wikipedia) does not cause those (so far), so only Wikidata.

And I would rather have someone fix this security-relevant feature than turn it off. If your anti-lock brakes make annoying noise, wouldn't you rather have them fixed than removed?

Yes, I would, but given the facts here...

1. Nothing relevant changed with LoginNotify in the recent past.
2. There was a Kubernetes related outage two days ago which coincides with when the problem started.
3. Not all toolforge hosted bots are affected. @MusikAnimal pointed this out yesterday on IRC that his bots were not affected.

...the probable cause is that your bot is logging in using a new IP address every time which isn't getting logged in CU tables against your bot's account.

Given all that, I'd not say this task is "high priority". We or ToolForge folks would probably get down to the cause and fix it but it won't happen immediately. I suggested you disable the notifications in the meantime if it's a huge problem to you. That's all.

I started getting similar messages at the same time for a bot for which I am the contact on enwiki. I disabled the notification itself in preferences. Possibly default changed? The k8s incident T182722: Ferm changes on the host node break networking for Kubernetes pods seems in no way related to this.

I think https://gerrit.wikimedia.org/r/#/c/398511/ will fix this issue - we need to backport it.

Mentioned in SAL (#wikimedia-operations) [2017-12-16T00:44:58Z] <demon@tin> Synchronized php-1.31.0-wmf.12/extensions/LoginNotify/includes/LoginNotify.php: T182867 (duration: 00m 57s)

@Magnus are you still getting the emails? At least for me they stopped when the above patch was deployed.

If these are logins from tool labs, its odd that LoginNotify::cacheLoginIP() isn't preventing the false positive, since it should always be basically the same IP (or at least in the same subnet)

From the debug logs it seems like no new notifications are being send out for ListeriaBot or QuickStatementsBot. Is that correct, @Magnus?

In T182867#3845744, @Bawolff wrote:

If these are logins from tool labs, its odd that LoginNotify::cacheLoginIP() isn't preventing the false positive, since it should always be basically the same IP (or at least in the same subnet)

It rotates a fair bit. I see at least 7 different subnets in the debug logs.

Same happens with my Irclogbot only at es.wiki (out of the five wiki it operates on). The bot just read abuselog from api without editing, confirming given "diagnosis" above.

@Niharika I have turned off notifications as per suggesestion

@Vituzzu Is this still happening for you?

@Niharika
Looks like the same happens with my bot user sartle.wiki.bot (doesn't make any edits, only get data) on www.wikidata.org. I had added question about this to the support chart https://www.mediawiki.org/wiki/Topic:U50nm1rlhgajf7wd.

I use https://www.wikidata.org/w/api.php with wikibase-api library (https://github.com/addwiki/wikibase-api) and three servers (prod/stg/dev) with different IPs that logins to the mediawiki through API. The issue is a lot of notifications about logins from an unfamiliar device and IP. Can somebody explain how i can prevent it (except for turn off a notifications)?

But now I'm not sure that the problem is related to different IPs. Probably I'll get the notification even if i will use my bot user only from prod environment

In T182867#3889818, @Alexey.sivets wrote:

@Niharika
Looks like the same happens with my bot user sartle.wiki.bot (doesn't make any edits, only get data) on www.wikidata.org. I had added question about this to the support chart https://www.mediawiki.org/wiki/Topic:U50nm1rlhgajf7wd.

I use https://www.wikidata.org/w/api.php with wikibase-api library (https://github.com/addwiki/wikibase-api) and three servers (prod/stg/dev) with different IPs that logins to the mediawiki through API. The issue is a lot of notifications about logins from an unfamiliar device and IP. Can somebody explain how i can prevent it (except for turn off a notifications)?

But now I'm not sure that the problem is related to different IPs. Probably I'll get the notification even if i will use my bot user only from prod environment

The probable reason is that your bot only logs in and doesn't make any edits. The IP(s) don't get recorded in the CheckUser table that way and every log in is treated as being from a "new" IP. Unfortunately I don't have a solution for you except for either turning off the notifications for this feature (you don't have to turn off notifications for everything) or making a few null edits (on different logins) from the bot on a sandbox page. That'd make sure the few rotating IPs get registered in checkuser and are no longer "new".

There is an ongoing ticket for recording logins in CheckUser and that would probably help with this problem. However, that will take some time to get built.

Using bot passwords seems like the easy way to get around this problem (the AuthManager login hooks don't get invoked that way). Or OAuth, but that needs to be supported by the bot while bot passwords need no special support.

Starting on December 20, I've been getting these emails for MusikBot II several times a day. It uses bot passwords, and logs in the same way as my other bot, MusikBot. In fact they're the same tool account on Toolforge. Both bots run every 5-10 minutes (yes it should probably stay logged in, but that's an aside), and usually do not edit after every login.

So the weird thing here is that only MusikBot II is affected, and that it suddenly started on December 20. Both bots have been running in the same way since LoginNotify was first deployed in 2017.

I can disable notifications, but MusikBot II is an admin and interface-admin account. It'd be much preferred to get the notifications if they are genuine.

Would it make sense to whitelist the Toolforge IP range? Perhaps using a configuration variable, since this is specific to WMF?

Do you actually log in? In theory bot password sessions do not expire.

In T182867#4870712, @MusikAnimal wrote:

Would it make sense to whitelist the Toolforge IP range? Perhaps using a configuration variable, since this is specific to WMF?

No. Nothing prevents an attacker from doing login attempts from Toolforge.

In T182867#4870816, @Tgr wrote:

Do you actually log in? In theory bot password sessions do not expire.

Yes, as far as I can tell. The bot has been successfully editing all this time. Nothing relevant in the logs.

Would it make sense to whitelist the Toolforge IP range? Perhaps using a configuration variable, since this is specific to WMF?

No. Nothing prevents an attacker from doing login attempts from Toolforge.

Ah, duh. I was thinking more that I had trust that my Toolforge account is safe, with my credentials visible only to my account. But you're right, if they manage to get the credentials by other means they can just login using a different Toolforge account.

Could it be something to do with the permissions the bot password has? That is seemingly the only difference between my two bots, in practice. Though, I started using the new bot password for MusikBot II in early November, and I didn't get emails until a month afterwards.

I highly doubt it's the culprit, but this change was just before I started getting emails: https://github.com/wikimedia/mediawiki-extensions-LoginNotify/commit/24bb65b54afc8ca4a68f31f72ef870c1c6ca57d9

The immediate cause is rMW0c1b6605eeed: Have BotPassword::login() call AuthManagerLoginAuthenticateAudit which adds the audit hook for bot passwords. I had to re-read the task about CheckUser not logging logins and LoginNotify not recognizing the bot because of that (if it does not handle cookies).

We pass in a parameter telling it's a bot password to the audit hook now, so that could be used to restore the status quo (although not getting notifications about suspicions logins to your bot is not great). Alternatively, add some kind of checkuser data on bot login? Although I would be worried about login spam which is not rare for poorly written bots.

In T182867#4870899, @MusikAnimal wrote:

Do you actually log in? In theory bot password sessions do not expire.

Yes, as far as I can tell. The bot has been successfully editing all this time. Nothing relevant in the logs.

I mean, does the bot log in every day? There shouldn't be any reason to do that.

If the bot does log in every day, does it handle cookies properly?

Could it be something to do with the permissions the bot password has?

Not very likely, the bot user account itself does not do anything during the LoginNotify checks/warnings, why would it be checked for permission?

Presumably one of the bots does CheckUser-logged actions and the other doesn't?

In T182867#4870899, @MusikAnimal wrote:

Ah, duh. I was thinking more that I had trust that my Toolforge account is safe, with my credentials visible only to my account. But you're right, if they manage to get the credentials by other means they can just login using a different Toolforge account.

Of course if IP checking did work as expected, LoginNotify would be no help in that scenario...
I guess in some glorious future Toolforge would use IPv6 and have different IPs for each account. Or sign requests with the name of the user who owns the request-making process, and then we could add that to the botpasswords restrictions syntax.

Starting sometime on 2019-02-24, my other bot started getting these emails too. I believe this happened around the same time as me moving the task from Trusty to Stretch.

In T182867#4981680, @MusikAnimal wrote:

Starting sometime on 2019-02-24, my other bot started getting these emails too. I believe this happened around the same time as me moving the task from Trusty to Stretch.

The move from the old Trusty job grid to the new Stretch job grid would have changed the IP address as seen by the production wikis, so this seems reasonable.

I see this item is still open, though no comments in three years.

I'm getting "Login to Wikipedia as Bot1058 from a device you have not recently used" emails. I don't get these messages when I log in directly from my desktop PC. I am in process of installing this process but was informed per T266300 that always logging in from the same devices – my PC and the "Toolforge bastion" – was discouraged. I briefly tried logging in via the "Toolforge GridEngine" but per T319590 that also was discouraged. I think I got these "from a device you have not recently used" when logging in via GridEngine but now I'm logging in via Toolforge Kubernetes and I don't understand why the emails keep coming – or why they shouldn't keep coming. If every Toolforge Kubernetes job is started from a new "container" which goes away after the job finishes, along with its cookies, then how can Toolforge Kubernetes ever remember any job that logs into it? At the moment I'm just creating one-off jobs. Will the "device you have not recently used" emails stop coming once I get this running via scheduled jobs? I guess I'll try and find out.

I switched to using OAuth2 for authentication, because it no longer requires the login step, I no longer get any notifications for this issue, (OAuth2 is also easier to implement support for than the standard MW API login process so it's a win for that too) so I'd probably recommend that.

In T182867#3889857, @Niharika wrote:

The probable reason is that your bot only logs in and doesn't make any edits. The IP(s) don't get recorded in the CheckUser table that way and every log in is treated as being from a "new" IP. Unfortunately I don't have a solution for you except for either turning off the notifications for this feature (you don't have to turn off notifications for everything) or making a few null edits (on different logins) from the bot on a sandbox page. That'd make sure the few rotating IPs get registered in checkuser and are no longer "new".

There is an ongoing ticket for recording logins in CheckUser and that would probably help with this problem. However, that will take some time to get built.

I think that was the issue for my refresh-links bot. To work around this, I did some one-off runs of another task this bot does which does actually make edits. After running that bot task a few times on the Toolforge, the emails stopped coming, even for the task that just refreshes links and doesn't make any edits.

There is an ongoing ticket for recording logins in CheckUser and that would probably help with this problem. However, that will take some time to get built.

Hmm, T253802 Configure WMF wikis to log login attempts in CheckUser

Further Notes As discussed further below, it turns out that some bots log hundreds of successful logins per hour (sometimes even per minute) and that could inflate the CU tables significantly. Therefore, we will exclude successful login attempts from the CU logs kept on WMF wikis.

Maybe just include the first few but exclude those that exceed the minimum number that triggers the automated emails.

Syncing description from the dup report at T349336 as it gives much more detail and repro steps.

FYI, the apparent known workarounds include:

• Disable this type of email in your preferences ("Login from an unfamiliar device")
• Use cookies to prevent your bot from having to login on every run
• Switch to OAuth2

Once T345052: LoginNotify seen subnets table gets deployed and the performance of checking whether the login is from a known subnet is much improved, maybe we could get more aggressive about updating the list of seen subnets after a warning is sent?

I got a boatload of these "login from a device you haven't recently used" messages on October 14 (and a few before that), but couldn't be bothered to report the problem. I assumed that it was a system problem and not someone actually hacking my password. Glad to see that someone else reported it.

My solution was to simply (temporarily, perhaps) shut down my refresh-links bots, since for some reason that I haven't made a priority yet to investigate, they seem to have stopped working anyway. Maybe their failure is related to the issue(s) that caused this?

Thanks for putting me back in the loop, I'll keep subscribed to this.