Blocking disposable or temporary email addresses

[Yonas]

Hi,

Hope everyone is doing well!

What does the community think about adding a feature to Django where 
disposable or temporary emails are not accepted during account registration?

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c6101816-f267-4568-88d8-5b8f17bfd92en%40googlegroups.com.

Re: Blocking disposable or temporary email addresses

[Yonas]

Would syncing the block list from repos like 
https://github.com/disposable-email-domains/disposable-email-domains 
(actively maintained since 2014) ease the burden of updating the list?
On Thursday, May 12, 2022 at 12:44:28 AM UTC+3 James Bennett wrote:

> On Wed, May 11, 2022 at 2:21 PM Yonas  
> wrote:
>
>> What does the community think about adding a feature to Django where 
>> disposable or temporary emails are not accepted during account registration?
>
>
> I used to try to do this in my django-registration package, but eventually 
> gave up on it because maintaining an up-to-date list of all possible 
> domains and other patterns was not feasible. I expect the same would be 
> true with Django — it would require frequent updates to the list of 
> domains/patterns to block, and people would complain that the updates 
> weren’t fast enough, because Django only releases once a month (and that’s 
> assuming updates to the blocked email list would be considered for 
> inclusion in the monthly bugfix releases, rather than only at feature 
> release updates).
>
> So I expect this isn’t something Django could or should do.
>

-- 
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/b669801b-f695-49c2-9d04-2ff7db74dc58n%40googlegroups.com.

Decision on a 2FA PR

[Yonas]

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  based on an 
accepted ticket  and a 
discussion . 
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/be8111ae-91e5-45f0-b0b7-8ab737e40761n%40googlegroups.com.

Re: Decision on a 2FA PR

[Yonas]

Hi, Carlton!

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 battery included 
framework), developers, and users will immensely benefit from having a 
built-in 2fa.

Moving forward, 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/4656a44d-c993-44df-a7b6-b0bf7658b9a8n%40googlegroups.com.

Re: Decision on a 2FA PR

[Yonas]

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.

Re: Combining multiple aggregations with annotate()

[Yonas]

Hi Simon,

In addition to what's documented, that's another way annotate() gives the 
wrong result.

There are a lot of duplicates of #10060, and there are a lot of people who 
run into this issue. 

Given the age of the ticket and the lack of a simple backward compatible 
solution, what would be the way forward? Maybe breaking changes? Or 
updating the docs to show a safe usage of annotate()? Or throwing an error?

On Wednesday, January 5, 2022 at 7:44:11 PM UTC+3 charettes wrote:

> While addressing the issue is complex and will require quite a bit of work 
> to solve in a backward-compatible way I believe that it should be feasible 
> to emit a MultipleMultiValuedJoin(RuntimeWarning) with pointers for 
> alternatives (e.g. using subqueries) without too much hassle when 
> aggregation is performed and more than one multi-valued relationship is 
> involved.
>
> The docs you pointed at mention the multiple aggregation problem but a 
> similar thing happens when filtering against a multi-valued relationship 
> after a single aggregation[0] so the problem can be generalized to any form 
> of aggregation on a query that joins more than one multi-valued 
> relationship (n-to-many).
>
> Simon
>
> [0] https://code.djangoproject.com/ticket/33403
>
>
>
> Le mercredi 5 janvier 2022 à 09:59:24 UTC-5, Yonas a écrit :
>
>> In that case, at least there should be a warning message in the 
>> documentation. And what do you think of the example? Isn't it contradicting 
>> the documentation?
>>
>> On Wednesday, January 5, 2022 at 5:16:43 PM UTC+3 niccol...@gmail.com 
>> wrote:
>>
>>> I would be in favor of a real time information about the issue.
>>> Il giorno mercoledì 5 gennaio 2022 alle 15:13:17 UTC+1 Yonas ha scritto:
>>>
>>>> Hello,
>>>>
>>>> There's a ticket <https://code.djangoproject.com/ticket/10060> opened 
>>>> 13 years ago explaining a problem with combining multiple aggregations 
>>>> with 
>>>> annotate(). And the solution appears to be documenting 
>>>> <https://docs.djangoproject.com/en/4.0/topics/db/aggregation/#combining-multiple-aggregations>
>>>>  the 
>>>> problem.
>>>>
>>>> But for people skimming through the documentation, the message might 
>>>> not be noticeable. Showing the problem in a warning message could help 
>>>> draw 
>>>> attention better. It's used here 
>>>> <https://docs.djangoproject.com/en/4.0/ref/settings/#static-root> and 
>>>> in other places in the doc.
>>>>
>>>> In addition to documenting the problem, raising an exception might 
>>>> prevent developers from spending hours trying to debug their code.
>>>>
>>>> While the problem is recognized, there's an example  
>>>> <https://docs.djangoproject.com/en/4.0/topics/db/aggregation/#joins-and-aggregates>in
>>>>  
>>>> the documentation that shows the usage of multiple aggregations.
>>>>
>>>

-- 
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/4fec3010-2adf-4e1c-be85-4b66e9f20982n%40googlegroups.com.

Standalon Django ORM

[Yonas]

Hi,

Given the small number of Django ORM maintainers, making the ORM standalone 
will, among other things, increase the adoption of Django and bring in new 
maintainers.

An ORM inspired by Django ORM with over 3000+ stars: 
https://github.com/tortoise/tortoise-orm




-- 
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/2db8e46e-208f-45ce-9a0a-136686c99ef7n%40googlegroups.com.

Combining multiple aggregations with annotate()

[Yonas]

Hello,

There's a ticket  opened 13 
years ago explaining a problem with combining multiple aggregations with 
annotate(). And the solution appears to be documenting 

 the 
problem.

But for people skimming through the documentation, the message might not be 
noticeable. Showing the problem in a warning message could help draw 
attention better. It's used here 
 and in 
other places in the doc.

In addition to documenting the problem, raising an exception might prevent 
developers from spending hours trying to debug their code.

While the problem is recognized, there's an example  
in
 
the documentation that shows the usage of multiple aggregations.

-- 
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/09a8b1df-414e-4dd1-a202-0c6833b50c91n%40googlegroups.com.

Re: Combining multiple aggregations with annotate()

[Yonas]

In that case, at least there should be a warning message in the 
documentation. And what do you think of the example? Isn't it contradicting 
the documentation?

On Wednesday, January 5, 2022 at 5:16:43 PM UTC+3 niccol...@gmail.com wrote:

> I would be in favor of a real time information about the issue.
> Il giorno mercoledì 5 gennaio 2022 alle 15:13:17 UTC+1 Yonas ha scritto:
>
>> Hello,
>>
>> There's a ticket <https://code.djangoproject.com/ticket/10060> opened 13 
>> years ago explaining a problem with combining multiple aggregations with 
>> annotate(). And the solution appears to be documenting 
>> <https://docs.djangoproject.com/en/4.0/topics/db/aggregation/#combining-multiple-aggregations>
>>  the 
>> problem.
>>
>> But for people skimming through the documentation, the message might not 
>> be noticeable. Showing the problem in a warning message could help draw 
>> attention better. It's used here 
>> <https://docs.djangoproject.com/en/4.0/ref/settings/#static-root> and in 
>> other places in the doc.
>>
>> In addition to documenting the problem, raising an exception might 
>> prevent developers from spending hours trying to debug their code.
>>
>> While the problem is recognized, there's an example  
>> <https://docs.djangoproject.com/en/4.0/topics/db/aggregation/#joins-and-aggregates>in
>>  
>> the documentation that shows the usage of multiple aggregations.
>>
>

-- 
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/4510dfea-a7ba-4281-af9e-ebb190e4b6e1n%40googlegroups.com.

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

-- 
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/1d65ecc4-01a3-461e-bf72-e576a5860345n%40googlegroups.com.

Re: MFA (2FA)

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

Re: MFA (2FA)

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

On Friday, April 8, 2022 at 8:56:18 PM UTC+3 f.apo...@gmail.com wrote:

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

-- 
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/2f6fc6f6-859c-417e-9917-c8aa50323249n%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 <https://fidoalliance.org/fido2/> 
(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 
>> > <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/78ddbfbf-00b8-44e7-a3ac-e837a742f1f5n%40googlegroups.com.