#8117 Implement core 2FA

v1.6.0
closed
Dave Brondsema
security (34)
General
nobody
2016-12-14
2016-08-15
Dave Brondsema
No

This ticket is for the essential functionality for TOTP 2FA, separate tickets for other aspects

Some details at http://mail-archives.apache.org/mod_mbox/allura-dev/201608.mbox/%3C28c7a399-86c5-5d75-dde4-2ab54fe7b3e4%40brondsema.net%3E

Discussion

  • Dave Brondsema

    Dave Brondsema - 2016-08-19

    Some nuances to consider:

    Bitbucket requires 2FA resubmission to view/update settings, not just password reconfirmation.

    Reconfiguration vs (re)adding a phone with the same key as before.

    • GitHub says "You’re about to change your two-factor authentication device. This will invalidate your current two-factor devices. This will not affect your recovery codes or fallback SMS configuration. Those can be updated on the two-factor settings page."
    • Bitbucket only lets you disable, then re-enable
    • Dreamhost has separate options to view your key, vs regenerate. I like this.

    Many sites will show you the text form of the key, so you can enter it manually. Not sure if this is really needed for anyone? Phones/apps without camera support?

     

  • Dave Brondsema

    Dave Brondsema - 2016-08-31
    • status: in-progress --> review
     

  • Dave Brondsema

    Dave Brondsema - 2016-08-31

    First pass of this is available in branch db/8117. There is some polish and email notifications I want to do for sure, and possibly some logic changes.

    • you'll need to run pip install -r requirements.txt to get new packages (do this within docker, if using docker)
    • you'll need to run python setup.py develop in the Allura dir, for it to know of new TOTP entry points (again, within docker if using it)

    Overall I'm not super happy about using a session variable for multifactor-username, but we need some way to store the current partially-auth'd username and we can't just put it as a hidden form field or something like that since the client could change it. We could do an encrypted form field, which would have the benefit of not having to clear out the session var when you go to other pages (which is there so a partial login doesn't stay partially auth'd). But it would mean setting up a good encrypt/decrypt logic for the form field. Maybe worth it?

     

  • Kenton Taylor - 2016-08-31

    As a first rev, this is looking solid in my view.

     

  • Dave Brondsema

    Dave Brondsema - 2016-09-01

    Thanks, Kenton.

    I have pushed several more commits just now that include email notifications, and visual cleanup. That covers everything I was planning on for this ticket.

     

  • Kenton Taylor - 2016-09-01

    Visual polish, notifications, test coverage, and general improvements all look good. Clear to merge IMO.

     

  • Dave Brondsema

    Dave Brondsema - 2016-09-06
    • status: review --> closed
     

  • Dave Brondsema

    Dave Brondsema - 2016-12-14
    • Milestone: unreleased --> v1.6.0
     

Log in to post a comment.