Hi, Thanks for getting back to me.
How difficult is it to introduce new 2fa options without deprecating the existing ones if the right design is in place? I do not expect it to be challenging. But one downside, among others, would be the maintenance burden. Correct me if I am wrong, but for a while now, some of the widely popular 2fa options are SMS, email, TOTP, and u2f (which no longer has an API in Google Chrome). There are not a lot of new additions to the list that are getting momentum except WebAuthn. The point is, it should be okay to choose one or two 2fa options and keep them. Having said that, the responses from some of the community members seem to give a conclusion for the PR. Regarding 2fa as a third-party package, reconsidering that would be good. While Django helps users choose a strong password, many compromised passwords meet regulatory requirements. Django (a batteries-included framework), developers, and users will immensely benefit from having a built-in 2fa. Moving on, seeing the role of WebAuthn in Django is interesting. It can serve as 2fa, an alternative to Django auth, or both. I think this is good enough to start the conversation. On Tuesday, June 7, 2022 at 11:06:41 AM UTC+3 carlton...@gmail.com wrote: > 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/06d07367-93dc-4b44-b04b-cd7fd899d77fn%40googlegroups.com.
