Hi Yonas. Thanks for your input here.
Two points: - I *think* one reason Django doesn't already have 2fa itself is that available methods have (up to now) each been problematic in their own way. The trouble with adding a sub-optimal approach into Django is that we're essentially stuck with it forever. We can't realistically add an option, have it widely adopted and then say, "Oh, actually, we're deprecating this, use New Hotness™ instead" — that's not what folks use Django for. So, when this has come up before, the answer has generally been to keep implementations in third-party packages, of which there are several options. - It *looks* like WebAuthn (and the whole Fido Alliance grouping <https://fidoalliance.org>) is the way forward now. Per-device keys, stored in secure enclaves, with biometric authentication, and OS-level and password manager app-level integrations, etc. **This** is what we should be integrating no? (This is a solution, finally we can agree is robust enough no?) Maybe either of those points are wrong but, I'd rather see effort going into "What does WebAuthn in Django look like?" — answering that would be a major contribution. Kind Regards, Carlton On Sunday, 5 June 2022 at 19:48:22 UTC+2 Yonas wrote: > Hi, > > In light of what happened to the ctx package, this is a good time to get a > conclusion on the following topic. > > I opened a PR <https://github.com/django/django/pull/15670> based on an > accepted ticket <https://code.djangoproject.com/ticket/25612> and a > discussion <https://groups.google.com/g/django-developers/c/T-kBSvry6z0/>. > The PR implements 2fa but excludes WebAuthn, leaving it out as an > alternative to Django password-based auth. But an idea on GitHub was > forwarded that the PR won’t be accepted without at least supporting > WebAuthn. > > While 2fa is one use case of WebAuthn, the primary use case, in my > opinion, is providing an alternative to or a replacement for password-based > authentication. Regardless of its use case, the implementation of WebAuthn > does not have a lot in common with the opened PR. > > Instead of taking the all-or-nothing approach, doesn’t it make more sense > to work on the opened PR--making Django more secure--and support WebAuthn > when someone in the future opens a PR for either or both of the use cases? > > Thanks! > -- 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/898b0499-d201-47a7-8bfd-4d026aeeafbbn%40googlegroups.com.
