MFA (2FA)

[Yonas]

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

[Tobias Bengfort]

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

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

[Yonas]

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.

[Florian Apolloner]

Hi Yonas,

On Friday, April 8, 2022 at 3:18:23 AM UTC+2 Yonas wrote:

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.

While it is not required to  cover every usecase, WebAuthn would be at the top of the list. I do not think adding MFA to core without having support for WebAuthn is going to  get much traction.

Cheers,

Florian

[Yonas]

Hi Florian,

WebAuthn promotes password-less authentication, so let’s treat it as an alternative to the Django auth system while implementing 2FA for the password-based Django auth.

[Florian Apolloner]

Hi Yonas,

that is an unfair characterization of WebAuthn. WebAuthn supports passwordless authentication as strong first factor (albeit often supporting a limited number of credentials because it requires storage on the device). But Webauthn also (and this is imo more widely used) supports a strong unphishable second factor. So no, we are not going to treat it as an alternative for the auth system; it is the one 2FA system that we want the most.

Cheers,

Florian

[Carlton Gibson]

> 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

[Yonas]

@Florian, you're right; it can be used as 2FA. But take a look at how members of the FIDO alliance describe WebAuthn.

1. The last two sections of the website (Member Perspectives on FIDO2 and FIDO in the News)

2. https://webauthn.guide/

[Tobias Bengfort]

Hi,

On 09/04/2022 11.35, Carlton Gibson wrote:
> 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".

I am not sure that the existing options are sufficiently mature.
django-otp certainly is mature, but it does not and never will support
WebAuthn[1].

Last time I checked I wasn't really happy with any of the other options.
That is why I started django-mfa3. But I wouldn't call that mature either.

I believe it would be best to first try out some different approaches in
third party apps and then integrate the "winner" (or parts of it) into
core. Those third party apps do already exist, but as far as I am aware
they are not widely used yet.

Is it possible to start some kind of poll? Options could include:

- "I already use 2FA with django, using the library …"
- "I already use 2FA with django, using custom code"
- "I do not use 2FA with django yet, but I would like to"
- "I do not use 2FA with django yet, and I do not intent to"

thanks
tobias

[1]:
https://github.com/django-otp/django-otp/issues/40#issuecomment-633079273

[Dan Davis]

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 at DjangoCon 2016 on this topic. At that time, we used django-cas-ng for a CAS implementation in front of NIH Login.  In the cloud we use python-social-auth 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.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@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.

[Tobias Bengfort]

Hi,

On 09/04/2022 20.50, Dan Davis wrote:
> MFA is typically built with some form of federated login

I am not sure that this is "typical", but I agree that many
organizations want to manage keys in a single place. The trouble with
WebAuthn is that is a challenge-response protocol, so you cannot just
use any existing authentication protocol and replace the traditional
password by an OTP.

I am not aware of any open protocol for doing federated WebAuthn (or
federated MFA in general) yet, but I must also admit that I didn't know
many of the acronyms from Dan's mail.

It seems to me like this is similar to AuthenticationBackend: there
could be a ModelBackend (provided by django) that stores MFA keys in a
model. But then there could also be other (third party) backends that
implement different federation protocols.

I think we need answers for the following challenges:

- How do we deal with the explosion of combinations? There are already
different AuthenticationBackends. To that we would add different MFA
protocols (TOTP, WebAuthn, …) and different MFA federation protocols.
For most of these it is mix-and-match. But in same cases the three
levels might also be tightly coupled.

- MFA often requires a two step authentication flow, either because we
need to generate a user-specific challenge or because we need to check
whether MFA is activated for this particular user. We need to figure out
how to support this in LoginView, especially the weird "half
authenticated" state.


- Different protocols need different UI (e.g. "enter a 6-digit code" for
OTP or "activate your token" for WebAuthn).

thanks
tobias