Jump to content

Community Wishlist Survey 2019/Anti-harassment/Add an option to require email address and username to reset password

From Meta, a Wikimedia project coordination wiki

Add an option to require email address and username to reset password

  • Problem: Trolls and LTAs have been knocking Special:PasswordReset with the intention of trolling and (currently) this cannot be prevented. Then I get password reset I did not request. While I know I have secure password (and 2FA) on both my SUL accounts and my email, it's annoying so it'd better if I can just prevent them. It sometimes gives the impression to ordinary users that their account is being compromised, which is not a good UX.
  • Who would benefit: Those who gets spammed with false password reset
  • Proposed solution: Have a OPT-IN checkbox on Preferences, turned off by default. The checkbox will require you to enter your registered email address AND your username to get a password reset. When you set this up, you know your email address, but trolls don't.
  • More comments:
  • Phabricator tickets: phab:T145952
  • Proposer: — regards, Revi 10:38, 4 November 2018 (UTC)[reply]


  • When I can use different mailadresses and I have forgotten which one is necessary for passwort reset? There should be a separate option to send a confirmation mail to the adress used.--Brainswiffer (talk) 07:24, 17 November 2018 (UTC)[reply]
    • That is not part of this vote. — regards, Revi 07:29, 17 November 2018 (UTC)[reply]
    • Currently, you just need to know one of the following: "Email address used for the account" OR "user name", so technically you do not need to know email address to send password reset. But this is being actively abused and one steward I know gets 20 passwords per week (or day, I don't recall). With my proposal, people who voluntarily choose to enforce strict requirement will need to know both "email address used for the account" AND "user name". It's a big difference. Since the change is supposed to be opt-in (you have to click a check box on Preferences, and save it - it is not enabled by default when you register or suddenly forced when you sign in) most ordinary users do not need to take any actions. — regards, Revi 08:08, 17 November 2018 (UTC)[reply]
  • Without going into all reasons why this does not work, this doesn't really work even if it is quite common. A real solution is based upon something an attacker can't know, not something that is just a little bit hard to know. So instead of using a mailaddress as the additional information you use one-time scratch codes, and store them as hash codes on the server. That means only the user knows the real scratch codes, but also that the user requesting the scratch codes must keep them safely. — Jeblad 08:05, 18 November 2018 (UTC)[reply]
Given our position on 2FA expansion and number of people losing 2FA & scratch code, that is not a solution as well. — regards, Revi 08:31, 18 November 2018 (UTC)[reply]
Sorry, but scratch codes are the only solution that works and can be proven to be secure. Email and SMS is not secure, and using those for reacquiring credentials can be circumvented. The ting you use to identify yourself can not be anything an attacker can know or easily regenerate. That include all kinds of smart questioning, means of communication, etc.
Note that the present implementation of 2FA at WMFs servers are defacto a single factor login. I leave it to the reader to figure out why.
Anyhow, there are a lot of information available about this, so it should be unnecessary to argue about it. — Jeblad 09:38, 18 November 2018 (UTC)[reply]
  • @Jeblad: you seem to be confusing security measures and anti-harrassment measures (and probably many other things too, judging from your single factor remark, but that's off topic here). Security-wise, we are worried about an attacker looking for vulnerable accounts (and not one specific account, as there isn't really any reason for an attacker to limit themselves to one), and it is always easy to find accounts with public email addresses. It does not matter though as the security of password reset does not rely on the email address being secret, or the attacker not being able to request password reset; it relies on the attacker not having access to the target's emails. Harrassment-wise, on the other hand, we are worried about the attacker targeting one specific user, whose email address is not known (if it is known the attacker has more direct ways of harassing them so they need to fix that first), so the idea proposed here works just fine. --Tgr (talk) 22:12, 25 November 2018 (UTC)[reply]
I'm probably quite stupid, but please discuss the facts, not the persons. This proposal is about a concrete implementation, and that implementation does not work. It fails on the assumption that "it relies on the attacker not having access to the target's emails." A determined attacker will only request a password reset by a specific communication system if he has access to that system. Whether that would be email, SMS, or whatever does not matter. — Jeblad 10:02, 26 November 2018 (UTC)[reply]
I don't think Tgr was saying you're stupid. Just confused. After I read your comments I get het impression that you are conflating security (the protection of authentication and access) with anti-harassment (making it difficult for jerks to bother an individual). Both are important. This proposal is in the latter category. It's about stopping people from spamming someone with password reset email notifications over-and-over, not about making the securing of an account stronger. I agree as a security proposal this would not have much impact, but as an anti-harassment proposal it's helpful for a lot of users. I get these false-positive emails with my staff account. Makes my heart jump into my throat a little each time. :) I'd gladly opt-in to this feature to make it a little more difficult for folks to mess with me. CKoerner (WMF) (talk) 16:18, 26 November 2018 (UTC)[reply]
Thank you for pointing out that I'm not stupid, just confused. I'll tell the professor next time that his ideas about tokens that are physical inaccessible for an attacker is a pretty dumb and confused idea. — Jeblad 20:42, 27 November 2018 (UTC)[reply]
I'm sorry my attempt at clarification frustrated you. I was just trying to help. CKoerner (WMF) (talk) 16:40, 29 November 2018 (UTC)[reply]
  • With a caveat: this is not foolproof. Many Wikimedia email addresses are easily guessed, or if you are a list-admin to a Wikimedia mailing list the information is out there. --Rschen7754 07:52, 26 November 2018 (UTC)[reply]
    • I assume there's no requirement that your list-admin email is the same as your wikimedia account email right? If so, with gmail and any similar systems you could easily use the plus trick to generate an email address that the attacker won't be able to guess unless you've contacted them over wikipedia email before while keeping everything together. e.g. use rschen7754+wikipedia7754@gmail.com for your wikimedia email. You can just replace your email address in wikimedia if it ever becomes public somehow. Of course you will either have to remember it or make sure you keep a record of the address e.g. by making sure you don't delete emails to that address in the account it belongs to. Nil Einne (talk) 12:40, 1 December 2018 (UTC)[reply]