Staff actions now log
Changed the login label to be an h3, rather than an error banner
Second factor rate limiting dropped down to 3/minute
Fixed formatting issues and failing tests
I haven’t yet gotten around to tackling the token re-use yet – that will be next on the chopping block.
Worked this week at getting up to speed with qunit, and moving forward on most of the review items.
Done:
Blocking previous codes - valid 2-factor auth tokens can only be authenticated once/30 seconds.
I played with updating the “last used” any time the token was attempted but that seemed to be overkill, and frustrating as to why a token would fail.
Translatable texts.
Move second factor logic to a helper class.
Move second factor specific controller endpoints to its own controller.
Move serialization logic for 2-factor details in admin user views.
Add a login ember component for de-duplication
Fix up code formatting
Change verbiage of google authenticator
Todo:
js tests
controller tests
Add modal for explaining what 2fa with links to Google Authenticator/FreeOTP
Questions:
For reviewers, would it be easier to squash my changes in a new commit, or have an incremental “since last review” commit? Regardless, I will finish writing the tests and other todo items, and push it back up soon.
For running qunit tests, is there a way of quickly running a single test? As I’m building out a suite, It would be great to be able to build out expectations without having to re-run all tests each time.
It doesn’t matter – whatever suits you best. GitHub has an option to show only changes since last review and we can always squash your commits when we merge the PR.
I’ve finished wiring up the tests this week, so I think I’m ready for the next batch of reviews. Travis (specifically yarnpkg) seems to be having some issue today with setting up some of the tests, so having some difficulty getting that sweet green checkmark sadly.
@sam re: naming conventions, I’d ideally be evolving the user_second_factors table to hold all second factor information, so you can easily parse all second factors via the type column. For this pass, this is a 1-1 relationship to a user with TOTP only, but as we add more this would become a 1-many, as I was following @riking’s suggestion for table structure above. That would allow for uf2, and back up codes all in a single table.
Done:
Rebased on latest master
add controller tests
second factor controller tests
change email tests
change password tests
admin login tests
add qunit tests
password reset
preferences
Add modal for explaining what 2fa with links to Google Authenticator, Authy, and FreeOTP
Fixes:
check for 2factor on change email controller
email controller - only show second factor errors on attempt
properly check against ‘true’ to enable second factor.
Alright, I’ve rebased on the latest, and implemented extra second factor check when logging in via email - this is back in working order with the latest version of Discourse.
I also check for the second factor param to determine how to rate limit, rather than check via a session/per IP, which slipped my mind before somehow.
I’ve decided to squash just so further conflicts won’t happen on earlier versions before I split out some of the logic to a separate second factor controller.
All in all, it looks all good and complete from here - Hoping the team finds the work acceptable soon!
This seems unusual. All sites I’ve ever used TOTP on require all devices to be configured at once (Google, Dropbox, Microsoft, Facebook, LastPass, Amazon…), and do not display the QR code ever again. Do you use TOTP on another system that displays the QR code multiple times?
Deutsche Bank e.g. has its own 2FA implementation (called photoTAN) and is allowing this. Therefore it’s also possible to revoke the rights for each 2FA enabled device afterwards.
So, there is not a big deal, if one device gets lost or isn’t right by your side. I have an old iPhone 5 (and won’t buy any time soon a far more expensive new iPhone), if I can do the same things on a larger display on my iPad mini 4 for a fraction of the price.
Hope, you‘ll understand my logic behind multiple 2FA-enabled devices
Oh, that would mean storing a different token for each device.
I’m always storing the QR code image in my KeePass database for later use. Has mostly the same effect and works on every site.
Nevertheless, storing the QR on some place has the same value for security like a saved password, if you can’t pair devices with each other and revoke their rights if necessary.
I don’t see much benefit in 2FA, if the OTP-client isn’t appropriately linked to the server. It would be great if, let’s say each user can configure up to 3 different clients. Nowadays it’s not unusual, that power users have multiple devices (Android, iOS and tablet)
Future iterations I’m definitely envisioning allowing multiple 2-factors, but allowing a single TOTP/user was already a very attractive milestone to hit. Having any 2-factor auth is already much more secure, as it prevents access even when the attacker has access to your email.