Re: MFA (2FA)

[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

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

Re: MFA (2FA)

[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/


On Saturday, April 9, 2022 at 12:35:31 PM UTC+3 carlton...@gmail.com wrote:

> > 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 
>> > . 
>> > 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/78ddbfbf-00b8-44e7-a3ac-e837a742f1f5n%40googlegroups.com.

Re: MFA (2FA)

[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


--
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/bdd1003e-bf0e-19a1-c1db-9b9731f24d39%40posteo.de.

Django issus

[Hanen Mdaghi]

hello !
I whish that you are fine, i try to migrate my model my model name is 
employee but it dosent work the issus msj is ImportError:cannot import name 
'employee' from 'polls.models'

-- 
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/997ff389-7ab0-4970-90fe-601fdcedee29n%40googlegroups.com.

Re: MFA (2FA)

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


On Thu, Apr 7, 2022 at 9:18 PM Yonas 
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
>> clear