Re: Adding a security concerned feature

['Aaron C. de Bruyn' via Django developers (Contributions to Django itself)]

On Wed, Dec 2, 2020 at 9:23 AM Collin Anderson  wrote:

> > combination of blocking IPs and having a different admin URL would raise
> the bar quite a bit.
>
> So having a different default admin URL would help, right?
>

Sure.  But so would disconnecting the network cable from your server. :)
It's all about practicality.

Using something similar to django-axes raises the bar quite a bit, but
simply obscuring the URL doesn't do much.

I have plenty of apps exposed with the admin URL being '/admin/', but no
one's been able to compromise the site because I use django-axes to block
repeated attempts, and I have a strong password.  On several of the sites I
require logins with a YubiKey.

In my worthless opinion, I think it would be better to leave it in the
urlconf but commented out with a note that says "you might want to change
the admin URL to something different before you enable it for $REASONS".
Maybe have something in the docs on deploying your code into production
that goes over it too.

-A

-- 
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/CAEE%2BrGqvVXrAZbWwuieitTVTNuKzR%2B%2BWWqc-6HsO4LO0OhvEog%40mail.gmail.com.

Re: Adding a security concerned feature

['Aaron C. de Bruyn' via Django developers (Contributions to Django itself)]

That's security through obscurity that isn't too difficult to get past.  It
certainly raises the bar a bit, but like you said, the root problem is
someone finding a login box and hammering away trying to guess usernames
and passwords.  I'm betting your 'standard' login box isn't difficult to
find if your site has one.  Once you have cracked an account, see if it
gets you into /admin.

I use django-axes.  If you keep guessing passwords, your IP gets banned.

Maybe a warning could be set that says "Your admin URL is at /admin, we
recommend you change that"?

I think the combination of blocking IPs and having a different admin URL
would raise the bar quite a bit.

-A

On Wed, Nov 25, 2020 at 6:51 AM Collin Anderson 
wrote:

> Hi All,
>
> I think at minimum we should change the default admin url for new
> projects, as that's very easy to do, and it does provide a lot of value for
> new projects. This helps Django to be secure by default.
>
> I use the default /admin/ url for my projects and bots are regurarly
> trying different password combinitations. In addition, security scanners
> are now starting to warn if you have an /admin/ url visible on your website.
>
> It would be a ton of work for me to change it, but it would be trivial if
> this were a new project.
>
> I think adding the project name as a prefix would help a lot and be very
> easy to do.
>
> https://github.com/django/django/compare/master...collinanderson:patch-14
>
> (and then the docs would need to be updated too.)
>
> Thanks,
> Collin
>
>
> On Thursday, November 19, 2020 at 7:11:59 PM UTC-5 arvind...@gmail.com
> wrote:
>
>> A security model doesn’t necessarily have to be any one thing that’s 100%
>> secure. It can be a combination of things which include “actual” security
>> features as well as plain ol’ obscurity.
>>
>> If I have to register the admin urls on a project, I make sure to setup
>> django-honeypot and move the admin site to something non-standard.
>>
>> Any one thing may not be doing much on it’s own. But the combination, if
>> messy enough to make someone give up, will give you a better overall
>> security situation.
>>
>> Just my 2¢.
>>
>> Onward,
>> Arvind
>>
>> On 19 Nov 2020, at 23:32, r...@whidbey.com wrote:
>>
>> FWIW, I agree with Tim and Carlton.  There doesn't seem to me to be a
>> compelling argument for recommending developers to change the default
>> "/admin" url.  Any security concerns would hopefully be addressed by actual
>> security safeguards rather than changing names to something non-standard.
>>
>> On Thursday, November 19, 2020 at 7:44:21 AM UTC-8 carlton...@gmail.com
>> wrote:
>>
>>> On this topic, a ticket proposing to prepend the project name to the
>>> `admin/` URL in the default project template was opened.
>>> https://code.djangoproject.com/ticket/32209
>>>
>>> Given that it's the exact discussion we're having here, I've paused that
>>> to see if there's a consensus for a change.
>>>
>>> Thanks. C.
>>>
>>> On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com wrote:
>>>
  I've got this idea with the usage of json files that require some keys
 which is authenticated for a single user which seems to excite me for fact
 that if this was similar for admin/, then it'd give django a overhead
 advantages for future use.

 On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson, 
 wrote:

> I think I'd come down as -1 for a system check here...
>
> They're not costless, there's a tendency to want to add a new system
> check for every possible configuration choice, but, beyond implementing 
> and
> maintaining, the danger is it leads to too much noise.
> If you get a system check warning, you shouldn't be tempted to ignore
> it. In general I think reserving the built-in checks slightly means they
> don't get devalued. (Folks are free, and encouraged, to implement, and
> share, their own checks to enforce project-level standards.)
>
> I think it's not sufficiently clear-cut that using `/admin/` is a bad
> idea to justify including a check.
>
> (On a personal note, I like to use `/admin/`, configure nginx to only
> serve the admin from the localhost, and then use an SSH tunnel to access 
> it
> remotely, so I'd have to silence a system check here.)
>
> C.
>
> On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany
> wrote:
>
>>
>> Hi,
>>
>> I wasn't convinced about changing the 'admin' path until recently. My
>> reasons to change the path of 'admin' are:
>>
>> -A bit less likely to be affected by bugs like
>>
>> https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
>> : at least the site wouldn't appear in automatic scans for
>> vulnerabilities (if checking Django versions based on the admin
>> template, etc.) . The bug/exploit might have been known before the

Re: Making startproject's settings more 12-factor-y

['Aaron C. de Bruyn' via Django developers (Contributions to Django itself)]

Not everyone runs containerized.

I think some settings shouldn't be prefixed--i.e. DATABASE_URL is a pretty
common one.

-A

On Tue, Jul 7, 2020 at 12:40 AM '1337 Shadow Hacker' via Django developers
(Contributions to Django itself)  wrote:

> Do we really need DJANGO_ prefix on env vars ? In my first years of
> practicing 12-factor I used such prefix, but the last 5-6 years I let it
> go, because I just ended up with a list full of DJANGO_ variables in a
> containerized where only Django is running.
>
> --
> 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/3mulSta40m2DoZMPITSVrn3XE4xm_9NBbL1CMxtE8MqCnFqR-KT_RAOpxqfhH7Gn_6he9QkZ0z0HN0O2y2GAz8ifdQFghXcjfOMQF_wsUgs%3D%40protonmail.com
> 
> .
>

-- 
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/CAEE%2BrGrT6wSqWXw-fFTPJTi0YaJ08OtuTubCcvbQDXTja4dseg%40mail.gmail.com.