Re: Tracking/logging bruteforcing, especially on admin accounts?

[Claude Paroz]

Le vendredi 20 mai 2016 02:44:41 UTC+2, Josh Smeaton a écrit :
>
> I understand the reasoning for "use the cache", but not every site has 
> caching enabled, especially lots of smaller sites. 
>

That's not true. When not specified, the cache backend default to the local 
memory cache:
https://docs.djangoproject.com/en/1.9/topics/cache/#local-memory-caching

It's per-process, so not optimal, but still, Django can count on a default 
cache.

Claude 

-- 
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 post to this group, send email to django-developers@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/84ae5248-5153-47ec-bc84-1535ea82ff43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tracking/logging bruteforcing, especially on admin accounts?

[Josh Smeaton]

I understand the reasoning for "use the cache", but not every site has 
caching enabled, especially lots of smaller sites. A separate table could 
be used for tracking attempts, and cleared out per user on successful login 
attempt/ip address. This table would not need to be huge if designed with 
performance in mind. Caching could be layered on (check cache for bans but 
not for maintaining counts) or we could have a cache backend in addition to 
a database backend. I'm aware that django has a database cache backend, but 
any database solution in this space should be designed with the database in 
mind and not just essentially blob storage.

For what it's worth, I've used django-axes 
(https://pypi.python.org/pypi/django-axes) with some success in the past 
and will probably use it again for my current project. I don't think the 
username based protection is adequate though:

AXES_LOCK_OUT_BY_COMBINATION_USER_AND_IP: If True prevents to login from IP 
> under particular user if attempts limit exceed, otherwise lock out based on 
> IP.
>

Distributed attack on a particular user would not be caught in this 
configuration. 

Cheers

-- 
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 post to this group, send email to django-developers@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/dcb1395e-c93a-410e-839d-3c06f39d8d40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tracking/logging bruteforcing, especially on admin accounts?

[Florian Apolloner]

On Thursday, May 19, 2016 at 1:57:50 PM UTC+2, Aymeric Augustin wrote:
>
> Django’s “last_login” field in the user model is a common cause of 
> performance issues in large sites. (I believe it’s required to secure 
> password resets so we can’t remove it.) Let’s avoid adding more fields with 
> similar behavior. (The PostgreSQL experts subscribed to this mailing list 
> should be able to confirm that part.)
>

Not a postgres expert -- but an "often changing" field in a row certainly 
bloats the table. It would be nice if it were in an extra table, so 
rewriting the row does not include all the data like username and email 
(though I do realize this its probably not an option).

As for any changes to the admin itself, I am somewhat -0 to -1 on them, 
unless it can be clearly shown that we cannot do this via decorators etc in 
a generic way (there are probably plenty of views out there which could 
benefit from ratelimiting).

As for the rest of the proposed changes (see the gist):
 * Let's encrypt -- this should not be done by Django
 * 2FA: Yes, I'd like to see at least U2F and TOTP support ootb.
 
When it comes to tracking/rate limiting: No new fields for the models 
please, this should all be in cache (this is absolutely information you do 
not want to persist and also changes rapidly during attacks…)

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 post to this group, send email to django-developers@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/b0de12b2-71a8-4beb-b6a3-a8670eeef939%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tracking/logging bruteforcing, especially on admin accounts?

[Aymeric Augustin]

Hello Vaibhav,

> On 19 May 2016, at 08:59, Vaibhav Mallya  wrote:
> 
> 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 makes sense for django.contrib.admin. However I suggest to consider this 
feature as an enhancement of django.contrib.auth and consider a more general 
use case. That seems significantly more useful — assuming the generalization 
doesn’t make the problem intractable.

You should look at prior art such as django-ratelimit-backend.

> I am proposing a solution broken into two parts - tracking and enforcing.
> 
> Tracking - End goal would be logging SuspiciousOperation if appropriate 
> thresholds were crossed. 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_attepts_on_window_start, and checking / updating both on any / all 
> login attempts. Alternatively, simply serializing a Python heap-list for each 
> user may work.
> 
> Or we can simply leverage the cache backend to store state.

Please use the cache.

Django’s “last_login” field in the user model is a common cause of performance 
issues in large sites. (I believe it’s required to secure password resets so we 
can’t remove it.) Let’s avoid adding more fields with similar behavior. (The 
PostgreSQL experts subscribed to this mailing list should be able to confirm 
that part.)

> Enforcing - Rejecting login attempts [on any basis] is probably not a good 
> idea for a default - we can’t guarantee we don’t introduce some other 
> DoS-style attack vector. But there are some NIST/etc guidelines around, say, 
> forcing pauses between login attempts, exponential backoff, forcing 
> email-distributed tokens to be used, etc.
> 
> We’re already storing custom auth/session information for the Django user 
> model, so storing state/migrations/etc somewhere wouldn’t be too much of a 
> departure.

This is an interesting part of the problem. If it has been explored by current 
third-party solutions, then I’m not aware of it. Django should provide a 
reasonable default policy. Besides it would be nice to support selecting 
another policy. Such configurability would be consistent with how Django 
handles situations where various behaviors are acceptable.

-- 
Aymeric.

-- 
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 post to this group, send email to django-developers@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/BCA82CDC-FACF-41C7-985F-53E4D878B9CF%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Tracking/logging bruteforcing, especially on admin accounts?

[Cristiano Coelho]

IP based throttling like django-rest-framework would be ideal! I know there 
are some 3rd party libraries that tries to add ip based throttling to 
django although not as cool as drf ones.

El jueves, 19 de mayo de 2016, 8:11:27 (UTC-3), Vaibhav Mallya escribió:
>
> Hi everyone,
>
> I've been having a great chat with @jacobian here about potential security 
> improvements to the Django admin UI: 
> https://gist.github.com/mallyvai/bcb0bb827d6d53212879dff23cf15d03
>
> The admin UI is core to Django's value-prop, and it seems undersecured by 
> modern standards. I wanted to raise the possibility on this list of 
> guarding against brute-force login attempts on admin user accounts.
>
> You could imagine tracking / throttle in two main ways.
>
>
> 1. By originating IP
> 2. By number of login attempts on a user account
>
>
> 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.
>
> I am proposing a solution broken into two parts - tracking and enforcing.
>
> Tracking - End goal would be logging SuspiciousOperation if appropriate 
> thresholds were crossed. 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_attepts_on_window_start, and checking / updating both on any / 
> all login attempts. Alternatively, simply serializing a Python heap-list 
> for each user may work.
>
> Or we can simply leverage the cache backend to store state.
>
> Enforcing - Rejecting login attempts [on any basis] is probably not a good 
> idea for a default - we can’t guarantee we don’t introduce some other 
> DoS-style attack vector. But there are some NIST/etc guidelines around, 
> say, forcing pauses between login attempts, exponential backoff, forcing 
> email-distributed tokens to be used, etc.
>
> We’re already storing custom auth/session information for the Django user 
> model, so storing state/migrations/etc somewhere wouldn’t be too much of a 
> departure.
>
> Thanks!
> -Vaibhav
>

-- 
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 post to this group, send email to django-developers@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/f3619d7d-99e6-4061-9e5d-dff9e8f423cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.