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, <carlton...@gmail.com>
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
fix
was implemented (and everyone updated) so I prefer to not be
exposed
(or
less exposed)
-At the moment in Django there is no rate-limiting login attempts
"out
of the box" so I prefer to avoid the opportunity if possible
-Partially out of my control: an 'admin' user might have used the
same
password in another place and the password got leaked
Other people might have other reasons.
Cheers,
On Nov/18/2020, Tim Graham wrote:
I'm not convinced that a system check promoting security by
obscurity
adds
much value. The original poster wrote "sometimes it can be a
security
concern." Maybe that's the case (how so?) but for most sites I
would
say
it's not.
On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina
Estany
wrote:
Hi,
On Nov/16/2020, Carles Pina i Estany wrote:
Either way: I'd be happy to write a django check to make sure
that
'admin/' is not routed to admin.
Regarding this check: this morning I've done a very
preliminary/for
fun
draft to play with.
https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1
I'm not sure what is the best way to check if /admin is routed
to
django.contrib.admin. At the moment it's doing:
resolve(admin_url)._func_path ==
'django.contrib.admin.sites.index'
Yes, I know! :-)
I could also do something along the lines of:
resolve(admin_url).func.admin_site == admin.site
This causes problems on the unit test side (need to import
admin.site).
Still I don't really like it.
Does anyone have any better suggestions or comments? (or code
pointer).
Otherwise later on I'll have another look.
Thank you very much,
--
Carles Pina i Estany
https://carles.pina.cat
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/df485a53-2ad2-461f-95c8-f8f3857d67dbn%40googlegroups.com.
--
Carles Pina i Estany
https://carles.pina.cat
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/61afea37-34af-4271-91cb-e4a116c1eb71n%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/61afea37-34af-4271-91cb-e4a116c1eb71n%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/728e66df-9340-45da-96e0-cbc969e05f6en%40googlegroups.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/D4F8CDD1-A92C-4C98-B4F0-0560D3480DEE%40gmail.com.
