In this question and this question, the feature requests to implement two-factor authentication (2FA) were rejected.

This answer proposed to use Google or Facebook login for 2FA, but this question proved that occasionally Google login can fail, due to issues on Google's end. Furthermore, some previously available third party authentication methods like Yahoo! login became discontinued. This may happen to current methods too.

Due to this, users, especially moderators, cannot delete their email-and-password-based login and rely only on Google login, to avoid being locked out of their account. On the other hand, the email-and-password-based login is not secure enough without two factor authentication.

I suggest that Stack Exchange implements an optional simple TOTP two-factor authentication.

It would be optional in the sense that the user can turn it on or off manually in the menus, and by default, it should be off. This will not disturb existing users and will also not complicate new sign-ups. At his or her convenience, the user can go to the menus and turn it on or off.

A simple TOTP does not require storing phone numbers and sending SMS. It requires only the storage of a simple shared secret key that the user scans as a QR code or enters manually, into apps such as Google Authenticator or Authy.

What if the user forgets his/her password and/or loses his/her device?

In this case, the existing email-based password reset method can be used, which should automatically revoke the TOTP 2FA. So, after resetting his password, the user needs to setup TOTP 2FA again, if he/she wishes to.

From a technical point of view, I think passwords are perhaps stored as hashed strings. Now in addition, Stack Exchange just needs to store this shared secret key with encryption and ensure that it's not exposed to unauthorized persons. The Stack Exchange servers also need to regularly synchronize time. There is no need for storage of phone numbers (which is privacy-relevant) and sending SMS (which requires additional costs and may not be supported for all countries of the world). So, I don't think this proposal should be technically difficult or costly to implement. Of course, it will be tedious to implement, test and ensure that it's secure, but I don't think that it will be technically difficult. I don't work for Stack Exchange, so I'm just guessing here.

TOTP is very widely used nowadays, including by Google, Facebook, Instagram, GitHub, LinkedIn, Twitter, Coursera, Discord, Bitbucket, etc.

If the user does not want to use authenticator apps by big corporations, then there are also FOSS TOTP authenticator apps available, like FreeOTP Authenticator and andOTP.

  • 1
    How many users want this? Maybe this topic is something for the Site satisfaction survey or even The Developer survey. Once those results are in you can status-decline this based on facts ...
    – rene
    Commented Oct 12, 2020 at 6:58
  • 4
    @rene The necessity for 2FA should be decided based upon a security threat and risk analysis, and not based on a satisfaction survey.
    – ruben2020
    Commented Oct 12, 2020 at 7:08
  • 1
    Okay, fair enough. What is the threat and risk analysis for this case?
    – rene
    Commented Oct 12, 2020 at 10:53
  • 2
    @rene at least one of the mods has used the same email and password on one of the many sites that have been hacked in the last years and are part of the large credential dumps available. Some nefarious person uses these dumps to perform a credential stuffing attack on all mods with leaked credentials and achieves control over one or more mod accounts, and then proceeds to dump PII of the users of those sites. Commented Oct 12, 2020 at 12:42
  • 1
    @rene There are at least two possible threat scenarios for email-and-password-based login without 2FA/ MFA - 1) The attacker guesses the user's weak password e.g. using a dictionary attack or using the user's publicly searchable particulars. 2) The attacker phishes the user by sending an email to the user that looks legitimate but has a fake URL that looks similar to the real one. Then the user enters the username and password into the fake webpage. I think many users put their GitHub profile in their SE profile, which then may contain a valid email address.
    – ruben2020
    Commented Oct 12, 2020 at 12:44
  • 1
    @rene 2FA by TOTP is susceptible to phishing too, but the generated code only lasts for 30s, after which, it expires. On the other hand a phished username and password continues to remain valid until the user changes it.
    – ruben2020
    Commented Oct 12, 2020 at 12:53
  • So we're now happily listing threats. Except "your PII gets dumped" I see no risks listed. I mean: this is a Q/A site, not a bank.
    – rene
    Commented Oct 12, 2020 at 12:59
  • @rene Please see comments by Tom Wright and Izzy under this question and also the answer by Mad Scientist about moderators having access to PII data.
    – ruben2020
    Commented Oct 12, 2020 at 13:02
  • I have read all that. A lot of damage, reputation, correspondence in Jobs. If you want this implemented you need to put a number on that risk, preferable two, one for risk in dollars for each user and risk in dollars for SE the company. I'm not going to do that analysis because I can't be bothered but the FR needs a lot more justification then it currently has. There certainly is zero for the company so I doubt this will get on the roadmap ever but for sure this is not to be build in the next 6 to 8 weeks.
    – rene
    Commented Oct 12, 2020 at 13:12
  • 1
    @rene, okay let's include Teams in this. Not including 2FA unless you log in with Google, Facebook or Github could be an issue for some. And if you have a moderator account first it might also be easier to harvest a list of candidate emails from a specific team to try your attack on. And a Team could contain more internal company data you don't want other people to get (and they pay for this, unlike the community, so they might actually have something to say). Commented Oct 12, 2020 at 13:36
  • @MadScientist yes, bringing teams into this risk equation would be a smart move. SE will probably argue that Team Admins can control which domains are allowed access and on request a connection can be setup to a company controlled resource provider. It is worth reasoning about real money cases, not so about fake internet points.
    – rene
    Commented Oct 12, 2020 at 14:13
  • @rene How about risk in euros to the SE company from the What are the GDPR fines? page. The higher tier of fines: "The more serious infringements go against the very principles of the right to privacy and the right to be forgotten that are at the heart of the GDPR. These types of infringements could result in a fine of up to €20 million, or 4% of the firm’s worldwide annual revenue from the preceding financial year, whichever amount is higher."
    – ruben2020
    Commented Oct 12, 2020 at 14:52
  • 1
    I'm not a lawyer but you have to prove that not implementing 2FA is a serious infringement as meant by GDPR. I doubt it is specially because SE offers multiple alternatives that are not unsafe by default but only because the end-users lack a proper understanding or willingness to conscientiously use those authentication option and the credentials that are bound to it. But, yeah, if GDPR has something that might of value then it is worth adding that.
    – rene
    Commented Oct 12, 2020 at 15:23
  • @rene Yes. 2FA is not mandatory. It's currently only a recommendation, e.g. by ENISA's Guidelines for SMEs on the security of personal data processing: "Two-factor authentication should preferably be used for accessing systems that process personal data. The authentication factors could be passwords, security tokens, USB sticks with a secret token, biometrics etc."
    – ruben2020
    Commented Oct 13, 2020 at 4:48

1 Answer 1


I would not call 2FA simple at all. Anything that touches the core authentication part has the potential for disastrous security issues, so even if it were simple it still would require a lot of work to make sure it's safe. And one of the biggest issues when implementing 2FA is to work out a good reset mechanism when people inevitably lose their second factor. A simple email reset might be good enough in this case for regular users, and you could always add a manual review for moderators as they are pretty limited in number.

That said, I still think SE should implement 2FA. I might go as far as saying that SE must implement it for moderators given that they can access PII for every user in their site. SE is responsible for safeguarding that data, and that includes making sure that moderator accounts are secured properly. And employees have potentially even more access to sensitive data, they accounts should be secured by 2FA for sure.

I fully agree that you can't just rely on Google or other third-party authentication for this. I did very briefly consider using Google as authentication in a few places that didn't offer 2FA. In the end I found it too scary how much power that would give to Google to lock me out of those accounts. And this is not an entirely hypothetical danger, Google can lock your account if they think you violated their terms of service in some way.

I would though argue that if SE implements 2FA, they should also strongly consider WebAuthn. This is a relatively new standard, but it is pretty widely supported now in browsers. This would allow the use of hardware tokens in a way that completely eliminates the danger of phishing, and in my opinion it's far more convenient to use tokens than TOTP.

  • Thanks. TOTP (and any other 2FA) is tedious to implement, test and ensure that it's secure, but it's not technically difficult. That's what I meant by "simple". TOTP is very widely used nowadays including by Google, Facebook, Instagram, Github and LinkedIn.
    – ruben2020
    Commented Oct 12, 2020 at 8:09
  • 1
    @ruben2020 Perhaps, but considering the current backlog of bug reports I wouldn't want to suggest implementation of this without a lot more research than presented in the question.
    – Mast
    Commented Oct 12, 2020 at 9:30
  • Perhaps you can change your reasons with this argiument of Drew DeVault post. It's easy to implement. So no excuses. Commented Jan 3 at 21:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .