May somebody have a look at this?

Any account can use bot passwords? There's no limitation that restricts it only to bots.

You didn't understand me. Yes, I can use botpassword but I mean new similar feature.

I want my account to have multiple passwords and limiting available grants per this password as in botpassword feature.

In another words: I can't create a botpassword and login by Special:Login with this botpassword.

And why? For increased security for example when editing from public computers without any other account.

Any chance to get this implemented sometime? ;)

Another parallel request on enwiki from @Rehman : https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)&oldid=825396470#Separate_password_for_logging_in_with_limited_access

In reading, this would basically be BotPasswords - but also allowing interactive WEB editing. Perhaps that could just be another grant on the exiting system?

Really looking forward to this being implemented in the future. It's quite a significant feature in terms of security and user experience. Thanks Xaosflux, for pointing me this page :)

@Tgr - Would you mind commenting on the feasibility of this and/or if it fits a planned strategy (or if there is a competing strategy already?). Thank you.

Bot passwords were created specifically to circumvent security features that would cause problems for legacy bots (like 2FA or login notifications) so it makes little sense to use them for increased security. Also they are not really compatible with CentralAuth as each has its own session provider.

Hacking a botpassword-like feature on top of CentralAuth would not be too hard, as the core functionality is built into SessionManager; you'd only have to duplicate the bot password management UI and modify the login logic to handle the alternative password. It would be kind of inelegant though - limited-permission accounts have nothing to do with CentralAuth, it would make just as much sense to use them with the private wikis (core auth) or wikitech (LdapAuth). I'm not sure how one would go about adding that functionality in a way that's orthogonal to authentication and session providers.

If this is implemented as allowing botpasswords via web as well, why not, but then choosing own botpasswords will be a must. Otherwise, I'll have to open my password manager (LastPass) either on another computer I trust (why I'm editing on the public one then?) or on mobile or on the public computer itself (which will throw away almost any security improvement, because the keylogger can capture my LastPass password [or I can use one time login codes, that's why only almost] or simply download all my passwords since I'm authenticated). And even when using first two ways, I'd have to copy the bot password manually instead of clipboard or write it from my memory.

I really hope that none of this would be mandatory. I'm personally a fan of efficiency and proportionate security responses, of which this is not one.

@Ajraddatz my hopes would be that it would be like botpasswords, where basically you could log on with multiple passwords if you opt in to it, and when you opt in to it you can choose what access is available under your opt. You could lock certain passwords to certain IP's, make some edit-only, etc. Put everything entirely in control of the editor.

Thanks. I have no concerns if this is left to individual users to decide what hoops they want to create for themselves.

Listed on the CWL Survey for 2019, feel free to add support here: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Admins_and_patrollers/Allow_De-Privileged_logons_to_webui

Thank you @Xaosflux, {{support}}ed.

Was ranked #52 in the https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019 with 44 votes

I have proposed sort of the reverse of this: T210909: Introduce secure mode to MediaWiki

I see those two tasks as separate and we can do both of them. I don't see those two tasks as reverse of each other.

In T153454#4791681, @Urbanecm wrote:

I see those two tasks as separate and we can do both of them. I don't see those two tasks as reverse of each other.

Technically you could do both but it seems pointless. One lets you login into an alternative account with scope restrictions; the other makes scope restrictions default (with less fine-grained control) and you essentially need to log in again to access extra permissions. In terms of password theft, WebAuthn offers a superior alternative compared to alternative passwords; in terms of session theft, if the default session has limited privileges, that's on par with this proposal, except it has the power of the default.

I think there's consensus that we want some kind of "sudo mode" where you explicitly need to opt in (via some mechanism that a malicious script that just took over your browser cannot easily use) to user your more dangerous rights like checkuser. IMO the key differences for this proposal are:

1. It's opt-in, rather than forced on you.
2. It would reuse the grants mechanism so the user has finegrained control over what permissions are considered sensitive.
3. It would use a dedicated set of login credentials as the mechanism, rather than the system sending the user through a challenge (probably login with the normal credentials, although in theory it could be something different) when needed, or maybe when explicitly starting it by pressing a sudo button.

I think those are all inferior choices today (though not necessarily at the time the task was filed, when our 2FA support was poor):

1. Preventing privileged access from XSS is a key security feature, so we definitely need it to be non-optional. At best this proposal could only work if another, non-optin feature is implemented alongside it, but that would make it superfluous and confusing.
2. Having to figure out grants seems like an unnecessary chore to me. I don't think there's much use case for personalising which privileges need protection.
3. The third one is more debatable, but using login credentials seems both invonvenient to me (why not use just a checkbox, then? WebAuthn will protect against credential theft), and less flexible than a session flag (e.g. what if you want support for cross-wiki actions? bot passwords require logging in separately for each wiki).

So, I'd decline this.