> I do agree that a simple, opinionated solution in django itself could > push 2FA adaption and therefore general security on the web, which is > clearly a good thing. But I still think this works better in a third > party app such as django-mfa3.
I'd very much like us to have **some** story in core here. I guess we don't because it's complex, and there are lots of options. (…) One thought is to have **an** option in core and then document some alternatives. (But which option? Argh! The `…` above. And repeat) But — question — would documenting the existing options be viable? We don't normally point to (many) third-party apps in the docs. It's too variable, too difficult to maintain (etc). The exception is third-party databases backends, which we do link to. Would a topic doc explaining the basic idea and listing the options out-there be helpful to the community? I imagine between maintainers, and Security Team, and user community we could easily enough say both "Yes, this is a good option, let's include it" and "This package should be removed now". Kind Regards, Carlton On Thursday, 7 April 2022 at 20:55:32 UTC+2 Tobias Bengfort wrote: > Hi Yonas, > > the best place to start is probably to look at thrid party packages, e.g.: > > https://github.com/django-otp/django-otp > https://github.com/jazzband/django-two-factor-auth > https://github.com/mkalioby/django-mfa2 > https://gitlab.com/stavros/django-webauthin > https://github.com/xi/django-mfa3 (mine) > > I am not convinced that moving this into django is the best approach > though. There is just so many ways you can do MFA/passwordless. Recovery > in particular is complex with a lot of different solutions, depending on > context. > > I also noticed that you omitted FIDO2/webauthn from your list of > protocols. It is the newest of these protocols and requires a very > different architecture, but I guess that IETF and W3C had reasons to > choose it. > > I do agree that a simple, opinionated solution in django itself could > push 2FA adaption and therefore general security on the web, which is > clearly a good thing. But I still think this works better in a third > party app such as django-mfa3. > > best, > tobias > > > On 07/04/2022 14.42, Yonas wrote: > > Hello, > > > > The idea to implement MFA (2FA) has been brought up a couple of times > > over the past years. And the community seems interested. > > > > I am willing to implement this feature (HOTP, TOTP, and email). However, > > a QR code generator is required. > > > > If someone can help with this, it would be awesome. Otherwise, what do > > you think about bringing a third-party QR code generator into core? > > > > If both options are not feasible, displaying the secret key to the user > > is another alternative (not ideal). But the developer has the freedom to > > install a third-party package and show the QR code. > > > > Best, > > Yonas > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Django developers (Contributions to Django itself)" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to django-develop...@googlegroups.com > > <mailto:django-develop...@googlegroups.com>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/django-developers/1d65ecc4-01a3-461e-bf72-e576a5860345n%40googlegroups.com > > > < > https://groups.google.com/d/msgid/django-developers/1d65ecc4-01a3-461e-bf72-e576a5860345n%40googlegroups.com?utm_medium=email&utm_source=footer > >. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/73d0546d-ee9f-4404-a7e5-720016389e4en%40googlegroups.com.
