Closed micschk closed 7 years ago
What I forgot to explain; we are requiring users to enter an generated security-token upon activating 2FA (to make sure they've set up a 2FA device correctly). For this, the TOTP token has to be set up before activation and not change upon activation (or the user will indeed be locked out).
"we are requiring users to enter an generated security-token upon activating 2FA" <- can you explain how you are implementing this...
Like Google does; if you activate 2FA, you are required to enter a 2FA verification token right away. Only if this token is correct, 2FA will be activated for you (preventing people from activating 2FA without scanning the QR). Note; idea is to only show the QR only upon initial activation to prevent possible account sharing by having others scanning the same QR. Hence the extra verification to check if the 2FA is set up correctly.
Some more clarification on our implementation; Initial UI:
Upon checking 'Activeer' (=Activate 2FA), a QR is shown immediately, which a user is supposed to scan right away, this allows entering a verification token to activate 2FA.
Nice, is this a front end implementation as opposed to turning on in the CMS? Good to have some UI and User experience represented here, well done 🎉
Would be great to get something like this UI in the CMS for admins.content editors turning on 2FA.
See #22
Use case: we have a situation where users are testing the 2FA functionality and are locking themselves out because the token automagically changes between switching off & on again (this is not obvious for the user).
We would like to trigger a key update based on other factors than switching off & on (probably a more deliberate user-interaction like a 'regenerate key' button. Therefore, we'd like to submit a PR making the auto-regeneration a configurable option for more flexibility.