Privileged accounts (from sysop onwards) are now given the possibility to enable two-factor authentication for their accounts. Please add support so sysops and/or other accounts with elevated accesses that have decided to enable this security feature be able to continue using AWB.
Current workaround that anyone can use: Create and use a BotPassword
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T169397 [AutoWikiBrowser] Authentication/Login tickets | |||
| Open | Feature | None | T150582 Support two-factor authentication in AutoWikiBrowser |
Note: If you create a BotPassword for yourself, you can use that to log on to AWB even if 2FA is normally enabled on your account.
I don't think this task is valid. AWB should use either https://en.wikipedia.org/wiki/Special:BotPasswords or OAUTH. And probably atleast be able to tell a user that he cannot login using 2FA and direct him at bot passwords.
Yes, AWB should be probably also supporting OAUTH but I think it can be supporting also this. Do we have a task for that?
It's of course up to the developers of AWB to decide which support should be adding to the tool. To me it does not look harebrained or misbegotten to add support for 2fa with a prompt-for-token window when in the process of logging-in, if that can be achieved of course.
Regards.
The API supports everything AuthManager supports via action=clientlogin. Using action=login for anything except BotPasswords is deprecated, and AWB should use OAuth instead of BotPasswords for non-interactive login.
That sounds familiar, yup.
So, we need to encourage people to use BotPasswords (improve documentation etc), and look at moving action=login to action=clientlogin in the near future too
Just a reminder that AWB is used on other projects besides the WMF ones. So if OAuth is enabled, the application will still need to function without it on other projects. That could be why it wasn't done.
No, it's why Krenair said. Unless we share said key between Developers... Which is a pain, considering the code is in public code repos
And then any third party developers... would need to modify AWB to use a different OAuth...
No point
Bot Passwords would be the way forward, and/or supporting action=clientlogin instead which can allow 2FA to work
Better documentation is needed big-time; I went looking for info on this a few days ago and didn't find anything relevant until I finally stumbled across Special:BotPasswords itself (though now that I think about it, I probably should have checked Meta and MW.org instead of just en.WP).
Use an owner-only OAuth consumer and handle all OAuth data (consumer key, consumer secret, access token, access secret) as user credentials.
If you have enabled 2FA, then you could create a bot password (Special:BotPasswords) and login with those details. That way you can login without needing 2FA. (BotPasswords is IP restricted)
This came up at WikiConf North America today. I think there's been a bit of misunderstanding of this ticket. There's no need for OAuth support in AWB (nor does it make sense). Instead, AWB needs to switch to action=clientlogin, which will return a response prompting for 2FA if necessary, which the user should provide to complete the login process.
Support for owner-only OAuth does makes sense, it's basically a different type of password that is more secure and does not require 2FA. It's not user-friendly though and you are probably better off with bot passwords (which do not require any code change, other than maybe explaining the user how to use them).
action=clientlogin requires the app to implement an open-ended dialog system which is not really specified anywhere. It's a nontrivial amount of work, and I'm not sure it is worth the effort, nor that it is good security practice to train users to put their password and 2FA into random desktop apps they have downloaded from the internet.
Have there been any updates on this? 2FA usage has risen substantially since this ticket was opened, so this is a quite significant issue.
Why is it a significant issue? There is a clearly documented workaround in this task; which is possibly the best actual solution here.
And as per
the other option doesn't seem to be a good idea.
FYI: enwiki documented the workaround here: https://en.wikipedia.org/wiki/Wikipedia:Using_AWB_with_2FA
I think we should probably add something into AWB's UI, and probably better handling of any related error messages if user has 2FA... But beyond that...
You could also use OAuth 2.0 (non-owner-only), that's more convenient to the user (but takes some effort to implement).
We should probably have some kind of policy against bots / tools asking for unrestricted credentials (the normal password / 2FA), it's a huge security anti-pattern. "You should never give out your password to third parties" is one of the more fundamental security rules. There's all kinds of industry export to help / educate users on how to tell whether the browser asking for their password is legitimate. It's not really reasonable to expect users to be able to judge when a downloadable client is legitimate.
Why is it a significant issue? There is a clearly documented workaround
I first encountered the issue when AWB threw up a generic message saying "Login aborted". It took me a few minutes to realize that 2FA was probably the cause. Then another few minutes to start going through the bug reporting process and find this page/the en-WP workaround page. And then another few minutes to actually implement that workaround. So in total it probably cost me about 15 minutes to deal with. If we assume that that's typical on average, and then multiply by the dozens or hundreds of editors that encounter it in a given year as they enable 2FA, we're talking about a significant waste of editor time. So why is it a significant issue? That's why.
The very least that we should do is to make a clear error message that points people directly to the workaround. But even then, using a non-2FA bot password defeats much of the purpose of enabling 2FA in the first place.
OAuth 2.0 is, to my understanding, the centralized login system for Wikimedia, so switching to that seems to be the approach that would simplify things and reduce technical debt.
It does not, as long as you create the bot password with reasonably limited permissions. Admittedly not a user-friendly ask currently; see T290790: Group OAuth grants by riskiness (it's an OAuth task but the grant system is actually a core feature and shared by bot passwords) and T165219: Templates for owner-only OAuth consumers (this would have to be implemented differently for OAuth and bot passwords but at least the concept could be shared).
OAuth 2.0 is, to my understanding, the centralized login system for Wikimedia, so switching to that seems to be the approach that would simplify things and reduce technical debt.
I agree it's the best solution. It's a non-trivial amount of work for the AWB maintainers though, while bot passwords just work.