Skip to content
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

Closed
nh916 opened this issue Mar 12, 2021 · 14 comments
Closed

feature request: 2 Factor Authentication #2803

nh916 opened this issue Mar 12, 2021 · 14 comments

Comments

@nh916
Copy link

nh916 commented Mar 12, 2021

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

@9mido
Copy link
Contributor

9mido commented Mar 12, 2021

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.

@Glowsome
Copy link
Contributor

Glowsome commented Mar 12, 2021

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

@9mido
Copy link
Contributor

9mido commented Mar 12, 2021

@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.

@Glowsome
Copy link
Contributor

Glowsome commented Mar 12, 2021

@9mido solved - my bad

@9mido
Copy link
Contributor

9mido commented Mar 13, 2021

No worries @Glowsome just wanted to make it easier for all of us. Thanks for changing it.

#861

The 861 PR has some discussion on 2FA already. So maybe start there for something built in or make django-allauth-2fa better than it already is by adding yubikey support and fixing the various bugs.

@Glowsome
Copy link
Contributor

Glowsome commented Mar 13, 2021

@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.
This would (again IMHO) mean minimal changes in the project's code, while still honoring authentication contracts ( with 2FA/Multifactor) available on a/the IDP's end.
As OAUTH(2) means you are letting authentication being handles by an external (trusted) identity-provider you should also let the IDP decide on the way in which it will authenticate you, unless ( via the acr_values) you dictate to the IDP exactly HOW you want to authenticate.

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 ?

@9mido
Copy link
Contributor

9mido commented Mar 13, 2021

@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.

@Glowsome
Copy link
Contributor

Glowsome commented Mar 13, 2021

@9mido i am using an IDP based on Microfocus AccessManager ( formerly NetIQ... formerly Novell)

for a reference please see #2805

@pennersr
Copy link
Owner

Related: valohai/django-allauth-2fa#131

@pennersr
Copy link
Owner

2FA development is underway. Any early feedback is greatly welcome: #3383

@bufke
Copy link

bufke commented Oct 2, 2023

@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.

@pennersr
Copy link
Owner

pennersr commented Oct 5, 2023

@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.

@pennersr
Copy link
Owner

pennersr commented Oct 5, 2023

Closing this ticket -- allauth.mfa has been released.

@pennersr pennersr closed this as completed Oct 5, 2023
@bufke
Copy link

bufke commented Oct 5, 2023

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:

  • GlitchTip uses dj-rest-auth extensively with the oidc support patch and a new api to expose social application settings.
  • KoboToolbox uses a hybrid of allauth templates + custom api's

I'll investigate migrating my code to allauth. I'd rather just maintain my own API than the MFA implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants