2020 Authentication Initiativ

[Johannes Hoppe]

Hi there,

I wanted to start a longer discussion on authentication. I have been looked a lot into alternative Django authentication backends, to see what ideas people have come up with. Sadly, I also discovered may security issues while reviewing some prominent packages. Anyhow, Django started out with username and password, which for the time being was a good idea I guess. Looking forward, I believe it is a good time to reevaluate that concept for the decade to come.

There have been plenty new developments, 2FA, OAUTH2, SAML, OpenId (connect), OTP and the list goes on. Many of them even made it into proper standards and have been adopted in soft- and hardware.

I think to get the discussion into the right direction, we first need to figure out, what Django is supposed to provide.

IMHO Django should provide a secure and simple (for developers) out of the box solution. That allows anyone who doesn't hold a Phd in crypto science to build a secure web service.

As anything in Django, it should be extendable or swappable for more advanced use cases and there should be plenty well written documentation on how to do that securely.

With that idea in mind, I see a personal problem with password. Passwords have been proven to not be secure, mostly because people are using it wrong. 123456 is still the most commonly used password. So it is not strange to me, that everyone is looking for different authentication methods and developers use different authentication backends. I actually haven't used Django password authentication in the last 5 years and there are other like me, I presume. Out of that demand people even started building their own authentication backends. This is the point where I wished everyone had a Phd in crypto science. Bottom line, you end up with many unsecure services. The very thing Django should be good at, by my definition earlier on.

Anyhow, I am curious what your thoughts on this matter are. Mainly what you believe Django's place in all this is and how this could be implemented.

Best

-Joe

[Barnaby]

If we go to the most common use case, email + password is the current "default" of the web, rather than username + password. It would make sense for Django to use email + password by default.

It also feels like first_name and last_name have no place in AbstractUser and should me moved to NamedAbstractUser or something.

So we'd remove username, first_name and last_name by default.

Regarding other means of authentication, I don't know if Django should support any out-of-the-box. Magic Links could be a decent default but they do raise security issues and require email setup.

[Florian Apolloner]

Hi Joe,

uff you are bringing up a hard topic :) Yes I absolutely would like Django to have better support for WebAuth (u2f-like tokens at least), and probably another one or two (I'd keep the scope for support in Django small though once we know that the API works).

Getting this actually implemented might be a different story though. I am imaging quite a bit of work and effort. I think a first step would be to spec required features out a bit and then start working on a DEP. Probably raise some money along the way, because I imagine this to be a rather big project -- but the support is certainly there!

Cheers,

Florian

[Collin Anderson]

Email + password auth is definitely a wanted feature out-of the box, and probably a good first step would be to create a separate AbstractEmailUser or something like that. Seems to me AbstractUser shouldn't be changed for backwards compatibility reasons, but maybe something like a BaseAbstractUser would be helpful?

And here's a past discussion and ticket (from 5 years ago):

https://groups.google.com/d/topic/django-developers/7feYlp9HqKs/discussion

https://code.djangoproject.com/ticket/20824

Also related: UserCreationForm by default allows usernames that differ only by case

https://code.djangoproject.com/ticket/25617

--
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 post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2ec07906-8a2a-4b63-a850-99e8fef95b5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John D'Ambrosio]

Email and password is pretty well supported out of the box using the configuration options provided on the AbstractUser (USERNAME_FIELD). Slightly more complex cases like username and email both being valid login parameters require very thin wrappers. The greater discussion is about technologies like JWT and OAuth and LDAP, but I feel like those third-party integrations work pretty well and do not bloat all of Django since every team has different needs.

[NOTARO WEB]

Hello, this my first message... hi for everybody

I think it could be a micro-service... you would not touch what is there,  which is a huge advantage regarding compatibility.  We could start to monolith django and I think with this Auth history it would be a good opportunity. Abstraction for django-monolith with base conversation and then the Auth micro-service... and we open the community can create/improve other potential micro-service

Anyway... I would be happy to help.

Best regards

Jeff Notaro

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFO84S5ki%3DtuPCZyXf2e_%2Bq%3D7V8Q1a6RX3EJycx51BodwnJZBA%40mail.gmail.com.

[Johannes Hoppe]

Hi there,

@Florian, since I had so many PRs pending review, I had to find other ways to cause chaos ;)

Besides that I agree, this isn't an easy undertaking and a lot of time will need to be spend on the whiteboard to get this going. Maybe it is worth actually collecting a little bit of money for this. I am sure there are companies that would be willing to invest into a better authentication framework in Django.

When it comes to how this could looks like, I see two main pillars:

1. It needs to be extendable. Provide a great framework and let the community rise to the task implement the various systems.

2. There needs to be at least one solid out of the box solution, got get users productive from minute one.

With that in mind, I do see something, that would separate the User object from an authentication provider. Both being separate and swappable entities. In a way this is already the case with the user and authentication backend separation. However, the AbstractBaseUser does already implement a password, a natural key and suggest the implementation of a username.

All of which are not a given for all authentication mechanisms.

I would suggest as a first step to separate the field names from the object methods. Thanks to multi inheritance in Python this should be an easy enough task.

I will look into it a bit and propose something as a base for discussion.

Best

-Joe

On Thursday, April 11, 2019 at 1:45:14 PM UTC+2, NOTARO WEB wrote:

Hello, this my first message... hi for everybody

I think it could be a micro-service... you would not touch what is there,  which is a huge advantage regarding compatibility.  We could start to monolith django and I think with this Auth history it would be a good opportunity. Abstraction for django-monolith with base conversation and then the Auth micro-service... and we open the community can create/improve other potential micro-service

Anyway... I would be happy to help.

Best regards

Jeff Notaro

Am 10.04.2019 22:59 schrieb Collin Anderson <cmawe...@gmail.com>:

Email + password auth is definitely a wanted feature out-of the box, and probably a good first step would be to create a separate AbstractEmailUser or something like that. Seems to me AbstractUser shouldn't be changed for backwards compatibility reasons, but maybe something like a BaseAbstractUser would be helpful?

And here's a past discussion and ticket (from 5 years ago):

https://groups.google.com/d/topic/django-developers/7feYlp9HqKs/discussion

https://code.djangoproject.com/ticket/20824

Also related: UserCreationForm by default allows usernames that differ only by case

https://code.djangoproject.com/ticket/25617

On Wed, Apr 10, 2019 at 7:12 AM Barnaby <antoni...@gmail.com> wrote:

If we go to the most common use case, email + password is the current "default" of the web, rather than username + password. It would make sense for Django to use email + password by default.

It also feels like first_name and last_name have no place in AbstractUser and should me moved to NamedAbstractUser or something.

So we'd remove username, first_name and last_name by default.

Regarding other means of authentication, I don't know if Django should support any out-of-the-box. Magic Links could be a decent default but they do raise security issues and require email setup.

--
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-d...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2ec07906-8a2a-4b63-a850-99e8fef95b5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-d...@googlegroups.com.

[Dan Davis]

Focus is the biggest thing - with so many other packages such as python-social-auth and django-cas-ng and django-warrant providing some sort of Federated Login, I don't think it makes sense to try to incorporate social login.  However, it would be nice if out of the box could do a register, verify email, login flow, and using email or username as they key would be great.

Backwards compatibility is also important - with django-cas-ng providing authentication for all the django projects where I work, I still needed a back-door to allow AppScan to login as an admin user.   So, I make sure users gets a random password, even though we are logging in via CAS anyway.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1bbc83d2-552d-444d-8165-1341b76328c2%40googlegroups.com.

[Florian Apolloner]

Hi Joe,

On Thursday, April 11, 2019 at 4:56:05 PM UTC+2, Johannes Hoppe wrote:

@Florian, since I had so many PRs pending review, I had to find other ways to cause chaos ;)

Hehe probably, the autocomplete stuff is on my todo for the sprints (and selenium is mainly waiting for a merge).

I would suggest as a first step to separate the field names from the object methods. Thanks to multi inheritance in Python this should be an easy enough task.

Personally I do not think this should be the first thing to do. At least for me the most common way to login is still an identifier + a password in combination with a second factor. And since u2f/totp/webauth do not really need anything from the usermodel aside from a PK for a foreignkey or so, this would be a good starting point. I think that, if needed, cleaning up the user model would be technically easy but hard from a backwards compatibility perspective. Introducing a new authentication flow/pipeline while technically hard would probably be relatively easy to add (new feature and settings while still supporting the old ones for a while).

I will look into it a bit and propose something as a base for discussion.

Yes please, the more written things we have the more we can discuss it and have something concrete getting out of it.

Cheers,

Florian

[René Fleschenberg]

Hi

> Also related: UserCreationForm by default allows usernames that differ
> only by case
> https://code.djangoproject.com/ticket/25617

I would like to mention CITextField / CIEmailField here. It solves this
problem nicely, in my experience.

However, it is only available on Postgres, and it requires a database
extension that in turn requires superuser access to the database to be
installed.

Do you think it would be realistically possible to have a CITextField
that uses Postgres citext when available and falls back to Python in
other cases?

--
René Fleschenberg

[Johannes Hoppe]

So I spend a little time fiddling around Django to understand what is possible and where there might be room for API improvements.

I went with the hardest possible way, NO password, NO username. Just one time passwords send via email or SMS. Similar to Django’s password reset function.

I published my work just now, https://django-mail-auth.rtfd.io. I would recommend to have a look at the custom EmailUser that I built. There are a couple of functions and fields that need to be overridden. BUT to my surprise even the management command “createsuperuser” worked.

Anyhow, I am curious to get a little bit of feedback to further investigate the different possibilities and implications this might have for Django’s authentication framework.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/d92P2V0YrbI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f91b347e-7fc9-f559-c5d4-e2c1124aadfd%40fleschenberg.net.

[Florian Apolloner]

Hi,

On Friday, April 12, 2019 at 8:06:21 PM UTC+2, Johannes Hoppe wrote:

I went with the hardest possible way, NO password, NO username. Just one time passwords send via email or SMS. Similar to Django’s password reset function.

I do not think that is the hardest possible way and as your code shows it is quite easy. I think the goal here should be to allow second factor authentication via webauth etc -- ie anything that is multistep. I am not surprised that email login works easily, it is a single step process after all…

I published my work just now, https://django-mail-auth.rtfd.io. I would recommend to have a look at the custom EmailUser that I built. There are a couple of functions and fields that need to be overridden. BUT to my surprise even the management command “createsuperuser” worked.

You could have reused https://github.com/aaugustin/django-sesame for the signing stuff :)

Cheers,

Florian

[Florian Apolloner]

On Saturday, April 13, 2019 at 1:07:39 PM UTC+2, Florian Apolloner wrote:

You could have reused https://github.com/aaugustin/django-sesame for the signing stuff :)

Ok django-sesame goes into a different direction but might still be worth to look at it.

[Александр Овчинников]

IMHO Django should provide a secure and simple (for developers) out of the box solution.

 

I can't but agree with you. Today long (at least >15 characters [Chrome password manager], but > 20 is much better) passwords created and stored in password managers (some modern browsers include them or as alternative you can try 1Password etc.) are still good solution but looks a little bit outdated (there is better login experience).

"Django - The web framework for perfectionists with deadlines."

 

Today password-based auth is not for perfectionists. No longer. Perfectionists votes for passwordless login experience. It's E-mail authentication (if you think about sms-based authentication, then do not use it without 2FA, hackers may read your sms), some SaaS'es may create it for you (Auth0: https://auth0.com/blog/how-passwordless-authentication-works/) or hardware keys (Yubico: something like https://www.yubico.com/products/yubikey-5-overview/, also check about their support: https://www.yubico.com/2018/04/yubico-and-microsoft-introduce-passwordless-login/).

So. We would like provide ability to use passwordless (hardware keys, E-mail-based) with optional 2FA (via OTP app on smartphone), OpenID Connect (which uses JWT tokens, OAuth etc.).

[Johannes Hoppe]

Auth0 looks like a need solution! And yes, I am a bit YubiKey fan myself. Use it for 2FA and PGP, worth every penny.

--

--

You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/d92P2V0YrbI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/99cf381b-3c5e-4560-97c7-9b9e160a5500%40googlegroups.com.

[Robert Marsanyi]

Many of these auth systems are client/server, not going to be the simplest thing to configure the entire stack for simple projects/tutorials/testing environments and so on. I can definitely see having.a pluggable alternative to the contrib.auth package that implements all the client-side stuff, though. When setting up or modifying a project, select the alternative package, and be as agnostic as possible about the auth server-side; a service like Auth0 or AWS Cognito if someone has access to it, a separate private domain auth server, Google/Facebook/OpenAuth. A protocol like OpenID Connect has the virtue of working with lots of different auth services, so an OpenID Connect client might fit the bill.