In T158153#3032207, @Tgr wrote:

In scenario 2, the probabilities are exclusive and you can just add them together so the attacker's chance of success is 1E-6 * 1E4 = 0.01, exactly the same. (Actually very slightly larger but the difference starts at the fifth digit after the decimal point.)

In T158153#3031406, @Tgr wrote:

An attacker can already launch a year-long attack on the normal (non-scratch) tokens. That they change periodically does not protect against that at all.

In T158153#3031153, @Tgr wrote:

Whether the number to hit changes every once in a while or not makes no difference whatsoever when you are guessing randomly. For a small number of guesses that's a negligible difference.

In T158153#3030873, @Tgr wrote:

In T158153#3030807, @Parent5446 wrote:

Note that the scratch tokens operate under a different attack scenario than TOTP codes, and thus they cannot be the same format.

The task description already explains why that difference is negligible (a factor or of two at most).

Note that the scratch tokens operate under a different attack scenario than TOTP codes, and thus they cannot be the same format.

In T5311#2626174, @Sumit wrote:

@Parent5446 this task has been assigned to you. Do you plan on working on this or mentoring this for the upcoming Outreachy-13 round?

In T153691#2887943, @Bawolff wrote:

This of course is equivalent to exposing whether or not the user has OATH enabled, since an attacker could just use a dummy password and then see if they get an OATH prompt.

Note that this was achieved in https://gerrit.wikimedia.org/r/280672, so maybe this is more a bug with AuthManager than it is this extension?

In T152926#2869441, @Legoktm wrote:

Also, does this task need to be private? Anyone can look up channel modes.

I'm tempted to decline this, but maybe others feel differently.

In T145915#2792021, @Volans wrote:

My 2 cents:

• for the recovery tokens (scratch_tokens) hashing vs encryption depends on the UI, if the user should be able to view them again after the first generation or not.

It should be just that. I filed a bug for every difference between the two at the time.

In T131788#2707987, @bd808 wrote:

Should there also be a way to generate a new set of recovery tokens, or is the "fix" for that to disable and then re-enable OATH?

Is there some sense of a global site group name in CentralAuth? If there isn't then we should just have a config variable for this extension, rather than forcing the string "Wikimedia".

I'd remove it. I really do not remember why I added it, and if I added it because of people accidentally blocking themselves...well that was a stupid reason. If people want to block themselves, maybe it's for the best anyway.

They really should be hashed :)

Is there a scenario in which this can be reproduced? Or is it seemingly random?

I will check it out, although there's a strong possibility this was another bug caused by the lack of URI encoding. I will investigate and report back here.

I've lost track of exactly what features AuthManager supports, but does it allow storing of arbitrary user authentication metadata? Because then once Extension:OATHAuth is converted to use AuthManager, we can just have the authentication provider store and fetch the secret from the generic backend interface.

I am going to make separate tasks for some of the feedback.

• Google: They allow login if you have one of any two-factors available (i.e., they support SMS and phone call as alternatives to TOTP). Additionally, when logging in with 2FA, Google allows you to mark a computer as "trusted". You can use a trusted computer that is still logged in to disable 2FA. Otherwise, you need to file an account recovery form, which Google responds to manually after a few business days. Things they ask on the form (I presume they have a further protocol beyond submission of the form, probably involving submission of government ID):
  • The date you created your account and the date you last accessed it (required)
  • Your security question, if enabled (optional, even if the question is enabled)
  • Up to five email addresses you frequently contact and up to five Gmail labels you created (optional)
  • Your first recovery email address (optional)
  • Other Google products you use and approximately when you started using them (optional)
  • An explanation of how you lost access to your account
  • Contact information for sending the password reset
• Facebook: Submission of a government ID, or (strangely) you can take a picture of yourself holding a code that Facebook gives you.
• GitHub, Apple, and Dropbox: Does not offer account recovery at all. You either need a phone with SMS for backup, or another backup token of some sort. If you lose all of your 2FA, you have lost access to your account permanently.
• LastPass: They allow removal of 2FA from the account by just sending a confirmation email to the primary account email. If you lost access to your primary email, I am not sure what options are available.
• Amazon Web Services: You have to file a support ticket to remove 2FA, after which they call you on the phone and ask for some trivial verification information (such as your credit card number on file).

In T15303#2175293, @Galorefitz wrote:

In T15303#2173978, @Parent5446 wrote:

1. Have a single i18n message in plain text and then convert the message to HTML when needed. (This is the method @Galorefitz describes in T130490).

@Parent5446 I actually proposed the second method in my proposal, not the first, i.e.,

As a quick note for both this task in general and for @rosalieper and @Galorefitz, we spoke with @siebrand yesterday, and asked him about the two approaches for this task, i.e.:

In T131616#2173123, @ori wrote:

To reduce the attack surface. If it's not limited you could just create a million of them and ruin the feature for everybody by making Special:Newsletters time out.

Weird, I don't remember claiming this in Phabricator. Although I can work on it if @01tonythomas wants.

The only interesting question about this is: what about users who are added as publishers to other newsletters by other people? Do we block a user from being added as a publisher when they reach the limit, or do we only block the creation of new newsletters?

Yep I believe so, unless there are other logging actions we wanted implemented.

Literally the only place that error message is used is in the AbortChangePassword hook...

@Reedy Just so I know all the details, were you logged in already? And I presume your account has 2FA enabled on it?

@Reedy I cannot seem to reproduce this locally. Could you provide some reproduction steps? I've tried visiting Special:Userrights and other restricted pages while logged in and it did not bother me. All other functionality seemed to be working as expected.

Making public since the main bug this is a duplicate of is already public.

For some reason "wikipedia.com", and probably any other redirect domains the WMF owns, are not alt names on the certificate.

I have confirmed this in Chrome and Firefox. No warnings in Safari.

Some related tasks: T46788, T18435, T32574, T19544

I think this bug can probably be closed since the technical requirements have been fulfilled. However, I still think we should actually apply a specific strong policy to accounts.

@01tonythomas Just want to clarify. Should we as the mentors be rating these projects right now in the Outreachy application? And if so do we need to alter the Contribution status as well?

I do not think @VitaliyFilippov's patches and the Outreachy project are mutually exclusive. First, I want to echo @Aklapper and just say thanks to @VitaliyFilippov. Patches are always welcome, and save us a bit of work!

Just to clarify, that is completely false (in regards to the cookie being "malware").

My only concern with this would be if there are any remaining browsers that preserve the HTTP method with 302 response codes. IE will only do so with non-POST/HEAD methods like DELETE and PUT, so there's nothing to worry about there.

I agree that we should continue to have messages not be raw HTML, but that is a more general issue, and it does not really justify having an individual bug for every message that needs to be parse-ified.

Is there any consensus about whether a fix for this needs to be made (i.e., throw it through the parser and make a workaround for the little things)? Or can we close it as invalid considering, as has been noted, this is the least of our concerns with admin powers.

Mhm, I agree. Just wanted to make sure. The interface you posted looks good. I'm assuming the intention is to make it a value object. Should we have transformation functions? Like ->add( Timestamp $other ), which returns a new Timestamp?

Are we considering the idea of allowing callees to register new timestamp types, and have them associate a parser with that type? Or is the format list just something we're going to keep fixed?

The token input will soon no longer be on the login page anyway, but I am not sure how MobileFrontend renders extension special pages.

In T102254#1371220, @MF-Warburg wrote:

What is the problem with allowing user css/js on loginwiki?

Not something I can do. You have to make a project ownership request for Gerrit on MediaWiki.org I believe.

Not working on it at the moment, so I'll un-assign. Not sure if it's still an issue, but will try and find time to check later.

I think it would be wise to avoid inserting any sort of non-code-reviewed JavaScript onto loginwiki.

Ah thanks. That explains why I can't see it.

Maybe I'm just blind, but where is this email? I don't see a public email address anywhere. @Jalexander, did you succeed in removing it?

Also, were these tests run with PHP-FPM or some other FastCGI server?

First, agreed with @bd808, and to add on to that, it would make a lot more sense to just use a third-party library for this functionality in the first place, but of course that would require more cleanup work rather than quick hack.

Ah lol. Well in that case sounds good.

To be honest, I'm not exactly sure how useful this really is. MWTimestamp is just a wrapper around PHP's native Timestamp class, and the only additional non-MW-specific functionality it provides is a parser for a bunch of obscure timestamp formats.

Just to document the problem with this right now, here is the current workflow: