My intuition is that Webauthn will be hard to support because of the varieties of ways to secure the private key (Yubikey, HIDGlobal, etc.) and the complexities of managing key pairs without devices. PGP/GnuPG followed a trajectory where we had ways to secure email, but it was too complicated to achieve wide adoption.
Would it be better to support email only login in core, e.g. to support passwordless 1FA? This is something that shouldn't require much in terms of protocol support since Django's email support is so good no one needs to rewrite or support through libraries. This is only 1FA, but it is passwordless. It could be coupled with the use of something like Google Authenticator or MS Authenticator - not sure how hard this latter part is to put in core. MFA is typically built with some form of federated login, and most applications will fall into two camps (1) those needing federated business login for business purposes, or (2) those needing federated social login for better conversions. In the middle ground, buy vs. build probably applies since there are so many SaaS services here. Because of this, implementing login well with MFA is usually a matter of supporting a federated login protocol such as SAML, OpenID Connect/OAuth2, or CAS. And it is that server protocol that implements the MFA. Many users may not even choose their protocol. Once you have these protocols, MFA can be done via a Google or Github account. Since OIDC federated login can be purchased as SaaS within AWS, Azure, Okta, etc., that's the best protocol to support within a "generic" application at this time. There are already mature libraries that cover SAML, CAS, and OIDC very well and work with a wide range of Django versions. There is often some customization necessary for MFA with a particular federated login. Over many years I've had to write middleware (not Middleware) to support federated login based on a keypair where the private key never leaves my PIV card, and the public key (in terms of certificates) is authenticated by a CA so that it need not be registered with a server/registry. I did a lightning talk <https://danizen.net/anti-social-auth/> at DjangoCon 2016 on this topic. At that time, we used django-cas-ng <https://djangocas.dev/> for a CAS implementation in front of NIH Login. In the cloud we use python-social-auth <https://python-social-auth.readthedocs.io/en/latest/> in front of AWS Cognito in front of NIH Login. I've also worked with SAML to enable PIV command-line login to AWS, see https://nlm-occs.github.io/nlmfedcred/. All of these have required some middleware (a Backend and either a middleware or a set of decorators). P.S. - I don't speak for NLM or NCBI. NIH Login is no longer as "antisocial" as it was, it now does have buttons for "Google" and "Facebook", but NCBI still wraps it to make it easier to click to login - see https://account.ncbi.nlm.nih.gov/?back_url=https%3A//pubmed.ncbi.nlm.nih.gov/ . P.P.S - Most of the versions of OpenSSL out there do not support OpenSC (smart card), and due to the Heartbleed issue, most security professionals (if they pay close attention to Django libraries) will want libraries to link with LibreSSL instead. This may not be as large a deal on the server side, but it is a big problem with testing this using Python code - until CPython is built against a version of OpenSSL/LibreSSL that includes PKCS11, linking up with smart cards and keys will be somewhat difficult. On Thu, Apr 7, 2022 at 9:18 PM Yonas <ytilahu...@alumni.alueducation.com> wrote: > Hi Tobias, > > Thanks for the feedback. > > There are multiple ways to implement MFA, as you mentioned. But the goal > here is to provide a simple mechanism. It's "not necessary" to cover every > use case, and I believe that's where third-party packages come in. > > Based on a study conducted by Microsoft, a user account is "99.9% less > likely to be compromised if" the user uses MFA. So, it would be beneficial > to have this feature in Django. > On Thursday, April 7, 2022 at 9:55:32 PM UTC+3 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/87921818-06cf-4e1e-976f-69d444edbd15n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/87921818-06cf-4e1e-976f-69d444edbd15n%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/CAFzonYYiTSwRaS7p%2BKGcjnApQQ3EUotLkRER1S9VECHOpknwbA%40mail.gmail.com.
