[allura:tickets] #8119 U2F for multifactor auth

[Dave Brondsema <da...@brondsema.net>]

Reference material:

* [JS API](https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html)
* But Chrome doesn't implement the high-level API.  Firefox plugin has one form of it, but it can vary function signatures.  So, seems like common practice is to include a JS library like either of these:
    * https://github.com/google/u2f-ref-code/blob/master/u2f-gae-demo/war/js/u2f-api.js
    * https://demo.yubico.com/js/u2f-api.js
* https://developers.yubico.com/U2F/Libraries/Using_a_library.html has a basic tutorial, but is pretty light on details
* http://stackoverflow.com/questions/26637660/how-do-i-use-fido-u2f-to-allow-users-to-authenticate-with-my-website has more details, but uses older form of `register()` missing `appId` as first param
* python U2F library isn't documented very well, but you can look at the source:
    * https://github.com/Yubico/python-u2flib-server/blob/master/examples/u2f_server.py which uses a higher-level python API
    * the u2f_v2.py file/module within that package seems to be easier and more direct to use, and https://github.com/gavinwahl/django-u2f/blob/master/django_u2f/views.py has good examples of using it

I've pushed some work in progress to db/8119 which is a good start and working well, but for various reasons I'm not going to keep working on this right now.  One reason is that U2F is still forward looking, and since the common best practice is to require TOTP (since not all browsers and non-browser connections support U2F) so that means adding U2F on top of TOTP doesn't really add any true security benefit, TOTP & recovery codes are the weakest link.



---

** [tickets:#8119] U2F for multifactor auth**

**Status:** open
**Milestone:** unreleased
**Labels:** security 
**Created:** Mon Aug 15, 2016 03:56 PM UTC by Dave Brondsema
**Last Updated:** Fri Aug 19, 2016 07:58 PM UTC
**Owner:** nobody


As an additional 2FA option, implement support for U2F.  Some details at http://mail-archives.apache.org/mod_mbox/allura-dev/201608.mbox/%3C28c7a399-86c5-5d75-dde4-2ab54fe7b3e4%40brondsema.net%3E


---

Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/

To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.