mallyvai/django_admin_thoughts.txt

## django_admin_thoughts.txt
Django’s admin UI is wonderful, and a big part of the reason why we chose it for OfferLetter.io. Unfortunately the admin panel itself is extremely insecure, with simple password authentication and no modern security infrastructure.


Given how widely-used and critical this admin UI is, I think that adding better, modern security practices would go a long way to keeping Django safe. Some rough ideas are below, in rough order of ease of implementation.


> Logging CSRF exceptions as special SuspiciousOperation security exceptions. CSRF tokens/cookies exist to provide security, and if there is some rogue actor, I’d like to know about as soon as possible. This is easy now to do now using the 403 handler. But in my view, the sensible default here is to treat it as a security violation and SuspiciousOperation.


> Logging failed admin account login attempts as SuspiciousOperation (including the IP). This will be highly-leveraged - easy to implement and straightforward.

> First-class recaptcha integration.  ReCaptcha is public and free, and widely-used and well-supported. One wouldn’t have to store modify tables or store any state in the database. As a downside, it would introduce an important dependency on an external / third-party service. If the service was down, or the API changed, that would have to be accounted for quickly.


> Enforcing strong passwords for admin users by default. We force OfferLetter.io to use 1Password/LastPass, but there really should be a better sensible default here here to make sure people don’t accidentally do something really dumb - either making the user confirm they want a weak password, or rejecting weak passwords outright.

There’s also a race condition of sorts here - That is if a normal user is created at first, then has the admin bit set. One potential solution is to enforce the same standard for all users, not just admin.

> Throttling login attempts. You could imagine tracking / throttle in two main ways.

By originating IP in last N minutes
By number of login attempts on a user account in the last N minutes.


In my view, #2 would be the best starting point - there are going to be a relatively small number of admin accounts on the average Django site. Ergo, focused brute-forcing or spearfishing seems to be a greater threat than getting into an admin account via a lot of scanning.

This solution is broken into two parts - tracking and enforcing.

Tracking - We’d need to store server-side state. I don’t believe we don’t have a clean heap data structure across all DBs that the Django ORM supports, but we could, say, keep two additional columns on each user object: last_login_attempt_window_start, and num_login_attempts_on_window_start, and checking / updating both on any / all login attempts. Alternatively, simply serializing a Python heap-list for each user may work..
Enforcing - As with any failure mode, we can start by logging and then by ramping up strictness. Rejecting is probably not a good idea for a default - we can’t guarantee we don’t introduce some other DoS-style attack.

We’re already storing custom auth/session information for the Django user model, so storing state/migrations/etc here wouldn’t introduce anything too crazy.

> 2FA auth integration. There are Python / Django integrations that provide it, but it would go a long way to have first-class integration support in the framework. It would be time-consuming to add and support. It would also be incredibly valuable, and keep Django sites by default in line with Google, Dropbox, etc.

> LetsEncrypt integration. This would be incredibly hard, but LetsEncrypt is the new standard for HTTPS - it’s free! and providing first-class support such that one could push a button and update/revoke/etc certs would be grand. We (OfferLetter.io) have a poor man’s version of this right now to simplify the auth/reauth flow for manual cert deployment. Integrating this into Django would be hard, and probably not a great idea now, especially since LetsEncrypt itself is still rapidly evolving. But - it would be pretty damn cool! ^_^

While managing scope and creep is always challenging, one or two key improvements would meaningfully improve the security here. As a bonus, many of the features would be easily transferable to all user accounts, improving user confidence in general.

-Vaibhav
	Django’s admin UI is wonderful, and a big part of the reason why we chose it for OfferLetter.io. Unfortunately the admin panel itself is extremely insecure, with simple password authentication and no modern security infrastructure.


	Given how widely-used and critical this admin UI is, I think that adding better, modern security practices would go a long way to keeping Django safe. Some rough ideas are below, in rough order of ease of implementation.


	> Logging CSRF exceptions as special SuspiciousOperation security exceptions. CSRF tokens/cookies exist to provide security, and if there is some rogue actor, I’d like to know about as soon as possible. This is easy now to do now using the 403 handler. But in my view, the sensible default here is to treat it as a security violation and SuspiciousOperation.


	> Logging failed admin account login attempts as SuspiciousOperation (including the IP). This will be highly-leveraged - easy to implement and straightforward.

	> First-class recaptcha integration. ReCaptcha is public and free, and widely-used and well-supported. One wouldn’t have to store modify tables or store any state in the database. As a downside, it would introduce an important dependency on an external / third-party service. If the service was down, or the API changed, that would have to be accounted for quickly.


	> Enforcing strong passwords for admin users by default. We force OfferLetter.io to use 1Password/LastPass, but there really should be a better sensible default here here to make sure people don’t accidentally do something really dumb - either making the user confirm they want a weak password, or rejecting weak passwords outright.

	There’s also a race condition of sorts here - That is if a normal user is created at first, then has the admin bit set. One potential solution is to enforce the same standard for all users, not just admin.

	> Throttling login attempts. You could imagine tracking / throttle in two main ways.

	By originating IP in last N minutes
	By number of login attempts on a user account in the last N minutes.


	In my view, #2 would be the best starting point - there are going to be a relatively small number of admin accounts on the average Django site. Ergo, focused brute-forcing or spearfishing seems to be a greater threat than getting into an admin account via a lot of scanning.

	This solution is broken into two parts - tracking and enforcing.

	Tracking - We’d need to store server-side state. I don’t believe we don’t have a clean heap data structure across all DBs that the Django ORM supports, but we could, say, keep two additional columns on each user object: last_login_attempt_window_start, and num_login_attempts_on_window_start, and checking / updating both on any / all login attempts. Alternatively, simply serializing a Python heap-list for each user may work..
	Enforcing - As with any failure mode, we can start by logging and then by ramping up strictness. Rejecting is probably not a good idea for a default - we can’t guarantee we don’t introduce some other DoS-style attack.

	We’re already storing custom auth/session information for the Django user model, so storing state/migrations/etc here wouldn’t introduce anything too crazy.

	> 2FA auth integration. There are Python / Django integrations that provide it, but it would go a long way to have first-class integration support in the framework. It would be time-consuming to add and support. It would also be incredibly valuable, and keep Django sites by default in line with Google, Dropbox, etc.

	> LetsEncrypt integration. This would be incredibly hard, but LetsEncrypt is the new standard for HTTPS - it’s free! and providing first-class support such that one could push a button and update/revoke/etc certs would be grand. We (OfferLetter.io) have a poor man’s version of this right now to simplify the auth/reauth flow for manual cert deployment. Integrating this into Django would be hard, and probably not a great idea now, especially since LetsEncrypt itself is still rapidly evolving. But - it would be pretty damn cool! ^_^

	While managing scope and creep is always challenging, one or two key improvements would meaningfully improve the security here. As a bonus, many of the features would be easily transferable to all user accounts, improving user confidence in general.

	-Vaibhav