-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature request: 2 Factor Authentication #2803
Comments
https://github.com/percipient/django-allauth-2fa I too would love to have all users use 2FA with allauth directly built in. That package above can do it but I have found it to not be the best for a few reasons. It uses OTP which is less secure compared to physical hardware yubikeys https://www.yubico.com/blog/otp-vs-u2f-strong-to-stronger/. OTP can be okay (but not the best security) for most non-technical users since they probably don't even know what yubikeys are and could just download an authenticator app on their device. There is https://github.com/django-otp/django-otp-yubikey which you can use though which works with django-allauth-2fa but again it uses OTP. It is yet another github library to worry about besides just allauth. The maintainer could disappear and the one person maintainer is calling the shots instead of the entire django community (jazzband) which is a big downside. Allauth has this problem too. There is also webauthn https://webauthn.io/ https://www.youtube.com/watch?v=jilKhi67qG0 which should be used instead of OTP. It follows FIDO2 not FIDO1. Webauthn is newer and better and should be focused on when making PRs going forward. Then we have https://www.twilio.com/docs/sms which is for SMS messages. But SMS is not as secure as yubikeys. If someone were to make this built in, I would recommend a setting to enable / disable 2FA for all users or not. Or optionally allow the users to configure 2FA themselves. Forcing 2FA on all users on signups would be the best for account security but not all people would want that. |
I would suggest implementing usage of the acr_values as described on https://tools.ietf.org/id/draft-hunt-oauth-v2-user-a4c-05.xml |
@Glowsome Nice link but it does not work when you click on it. You need to copy and paste it into your browser to see it. |
@9mido solved - my bad |
@9mido Thankyou for the headsup, and yes i am new to this project .. i stumbled upon it due to work-related demands, so the refererece is well appreciated. IMHO : as stated above regarding 'doing 2FA/MFA' would be to request the authentication contract as configured on an IDP via the proposed/supported acr_values. I know one can (depending on the actual used IDP) set/force an authentication contract on that end for a connection/client, but from an application management perspective this should be 'requested' by the application itself, and the OAUTH(2) standard does offer it.... so why not use it to our advantage ? |
@Glowsome You're welcome. Sorry but I am not familiar with how Oath works at all and this is way outside my skill level for being able to implement any of this unfortunately. Who or what would the identity provider be in this case? It is a good suggestion if it has minimal changes to the code. The more info you can provide on how to do something like this the better for somebody with the skill level to take this on. |
Related: valohai/django-allauth-2fa#131 |
2FA development is underway. Any early feedback is greatly welcome: #3383 |
@pennersr regarding webauthn, I implemented a django MFA project here. I wonder what you think of my approach using the python package fido2. I save all keys in a UserKey model, much like your Authenticator model. It looks like your OTP approach differs in encrypting private keys? Perhaps I could contribute here, I would prefer to use your package and delete mine 😄 Mine also supports basic django admin integration and "remember me" device keys. If you like the fido2 approach, I could investigate the feasibility of contributing a pull request here. |
@bufke There is already a WebAuthn proof of concept in development over here: https://github.com/pennersr/django-allauth/tree/feat-webauthn, which indeed uses the fido2 package. From what I can tell -- must admit, I did not do a deep dive here -- your project seems to have a focus on providing a REST API. Now, allauth currently does not provide a "real" API (other than accepting XHR calls to some of its regular URL routes). That is indeed an area that needs to be looked into, as the current approach where other projects try to build APIs on top of allauth can result in a fragile setup. But, I wouldn't want to bring a REST API in scope at this point in time, as the PoC shows, WebAuthn can very well be supported without it. I do want to assess the API situation in the future, but here an integral approach would be needed covering all of allauth. |
Closing this ticket -- |
Feel free to reach out regarding an API. I think it's a more minor need. Right now I modify dj-rest-auth which imports allauth but the author would like to avoid depending on allauth. I wrote about my change here. Use case wise:
I'll investigate migrating my code to allauth. I'd rather just maintain my own API than the MFA implementation. |
Any chance we can add 2 factor authentication to django allauth for secure sign ins.
With attacks happening constantly and data breaches happening left and right I think having 2fa in Django allauth would be worthwhile to have a complete a secure authentication system for Django
The text was updated successfully, but these errors were encountered: