Re: Adding a security concerned feature

2020-12-02 Thread Daryl
My 2c: The analogy is pretty straightforward here; - changing the admin URL is like putting your house's front door key slot in a strange, unique place, so that additional *knowledge* is required to unlock it. - django-axes, fail2ban, etc is like having a bouncer standing beside the door, watching

Re: Adding a security concerned feature

2020-12-02 Thread '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

Re: Adding a security concerned feature

2020-12-02 Thread Collin Anderson
> 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? On Wed, Nov 25, 2020 at 10:11 AM 'Aaron C. de Bruyn' via Django developers (Contributions to Django itself) wrote: > That's security through

Re: Adding a security concerned feature

2020-11-25 Thread '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 i

Re: Adding a security concerned feature

2020-11-25 Thread Collin Anderson
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 p

Re: Adding a security concerned feature

2020-11-19 Thread Arvind Nedumaran
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 admi

Re: Adding a security concerned feature

2020-11-19 Thread r...@whidbey.com
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 Th

Re: Adding a security concerned feature

2020-11-19 Thread Carlton Gibson
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

Re: Adding a security concerned feature

2020-11-19 Thread Shoury Sharma
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:

Re: Adding a security concerned feature

2020-11-19 Thread Carlton Gibson
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

Re: Adding a security concerned feature

2020-11-18 Thread Carles Pina i Estany
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 t

Re: Adding a security concerned feature

2020-11-18 Thread Tim Graham
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 Esta

Re: Adding a security concerned feature

2020-11-18 Thread Carles Pina i Estany
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/199c2fb26d

Re: Adding a security concerned feature

2020-11-16 Thread Carles Pina i Estany
Hi Adam, Shoury, About '/admin' URL to not be routed to admin: I can't remember if this is documented in Django documentation (I can't find it right now). But a lot of documentation on the internet says to change, in urls.py, from path('admin/') to path('admin-something'). In my opinion the admi

Re: Adding a security concerned feature

2020-11-16 Thread Adam Johnson
Hi Shoury I agree that this is an easy thing to change to prevent discovery of the admin. I've done it on several projects, and I saw Will Vincent mentioned it in his recent article on security: https://learndjango.com/tutorials/django-best-practices-security Implementation-wise, perhaps we could

Re: Adding a security concerned feature

2020-11-10 Thread Arvind Nedumaran
The one I follow is to set an environment variable to see if it’s a public facing instance or a private one (disconnected from the internet) and use that as a condition, which when true will add some urls. It’s the same pattern you’ll follow when using something like Django debug toolbar - whe