Re: Feature idea

[Aymeric Augustin]

Hello,

> On 16 Nov 2016, at 21:22, Anthony King  wrote:
> Sending a link to set a password isn't much better.
> 
The cardinal rule of passwords is “you must be the only person who knows your 
password”. This means never writing it down anywhere, except in a proper 
password manager, and never telling it to anyone, *even* your IT staff — to 
fight social engineering attacks.

Sending a password in clear over email means the IT staff is okay with knowing 
the user's password. Disregarding their own guidelines sets a poor example and 
reduces their credibility about password management in general.

Of course, on most Django websites, someone who can create a staff user can 
also change the user’s password — it’s rare to give the “create user” but not 
the “change user” permission. I’m not making a technical argument here, I’m 
thinking of IT literacy and educating users.

> Perhaps a way to force a password change on login would be better, which has 
> more use elsewhere, such as being able to periodically force password changes

Forcing a password change on login is another interesting idea to solve this 
problem. That’s what ActiveDirectory has to do, because OSes don’t have the 
same password reset possibilities that web applications have.

However I think that would mean solving the general problem of password 
rotation. Django solved password validation recently; it could solve password 
rotation next. (Note that password rotation is controversial because it forces 
users to choose weak passwords with a basic rotation scheme like putting month 
number at the end, instead of storing strong random password in a password 
manager. Trade-offs.)

I still think a simple solution hooking into the current password reset 
mechanism, just with a different email template, could be a quick security win 
for a lot of Django sites. I’d encourage people to use it if it existed.

Best regards,

-- 
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/76AE3F1E-6C00-4E4E-86A7-4E1374FF20AF%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: #27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

[Raphaël Barrois]

On Wed, 16 Nov 2016 20:32:34 -0800 (PST)
Yo-Yo Ma  wrote:

> I'm not a fan of adding more complexity, for a couple reasons:
> 
> 1) you have the ['*'] option for local / office development
> 2) you can just add a record to /etc/hosts to point to the server and then 
> use a name like e.g., local-office - just
> update the record to point to whatever IP you're using st the time
> 

Since settings are Python code, you could also do the following:

ALLOWED_HOSTS = ['.mydomain.com'] + ['192.168.1.%d' % i for i in range(256)]

With this flexibility in mind, I don't think increasing the amount of wildcard 
options is required ;)

-- 
Raphaël

-- 
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/20161117093831.28cc1cd2%40ithor.polyconseil.fr.
For more options, visit https://groups.google.com/d/optout.

Re: #27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

[Aymeric Augustin]

Hello,

If changes are made in this direction, allowing ip address and ip network 
objects in addition to strings would likely be the best API: 
https://docs.python.org/3/library/ipaddress.html#ipaddress.ip_network 


That module is new in Python 3 but since Django is on the verge of dropping 
support for Python 2, the fancy new toys are available now :-)

-- 
Aymeric.

> On 16 Nov 2016, at 23:29, Thomas Turner  wrote:
> 
> Hi
> 
> The other day I raise a ticket to do with ALLOWED_HOSTS and it was suggested 
> that I post on this group before creating a patch
> The ticket is https://code.djangoproject.com/ticket/27485 
> 
> 
> The problem
> 
> Now that Django 1.10.3 forces ALLOWED_HOSTS on with debug I have a problem.
> The problem is that when I developing I use an ip-address range of 
> 192.168.1.*. 
> The Ip-address can change depending on the computer I use.
> so I required the ability to add wildcard partly in an hostname.
> ie 
> ALLOWED_HOSTS = ['192.168.1.*', '.mydomain.com']
> I have seen this solution that doesn't require Django to be changed however I 
> don't like it as I feel this could be a security issue
> ​http://stackoverflow.com/questions/37031749/django-allowed-hosts-ips-range
> 
> I happy to do a patch for this. What do people think?
> 
> Tom
> 
> 
> 
> 
> -- 
> 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/7c03baf9-8d87-4716-be66-f6a642721a77%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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/C401E4F8-F86A-4AD7-A70C-BBB7FE6C8E03%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea

[Curtis Maloney]

My solution to the "initial password problem" is to send a password 
reset token first...


And Django has this built in, handily :)

http://musings.tinbrain.net/blog/2014/sep/21/registration-django-easy-way/

It would be very easy to use the same approach for an "invite" 
registration pattern.


--
C


On 17/11/16 19:38, Aymeric Augustin wrote:

Hello,


On 16 Nov 2016, at 21:22, Anthony King mailto:anthonydk...@gmail.com>> wrote:

Sending a link to set a password isn't much better.


The cardinal rule of passwords is “you must be the only person who knows
your password”. This means never writing it down anywhere, except in a
proper password manager, and never telling it to anyone, *even* your IT
staff — to fight social engineering attacks.

Sending a password in clear over email means the IT staff is okay with
knowing the user's password. Disregarding their own guidelines sets a
poor example and reduces their credibility about password management in
general.

Of course, on most Django websites, someone who can create a staff user
can also change the user’s password — it’s rare to give the “create
user” but not the “change user” permission. I’m not making a technical
argument here, I’m thinking of IT literacy and educating users.


Perhaps a way to force a password change on login would be better,
which has more use elsewhere, such as being able to periodically force
password changes


Forcing a password change on login is another interesting idea to solve
this problem. That’s what ActiveDirectory has to do, because OSes don’t
have the same password reset possibilities that web applications have.

However I think that would mean solving the general problem of password
rotation. Django solved password validation recently; it could solve
password rotation next. (Note that password rotation is controversial
because it forces users to choose weak passwords with a basic rotation
scheme like putting month number at the end, instead of storing strong
random password in a password manager. Trade-offs.)

I still think a simple solution hooking into the current password reset
mechanism, just with a different email template, could be a quick
security win for a lot of Django sites. I’d encourage people to use it
if it existed.

Best regards,

--
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/76AE3F1E-6C00-4E4E-86A7-4E1374FF20AF%40polytechnique.org
.
For more options, visit https://groups.google.com/d/optout.


--
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/694f60cb-bcd8-cc32-fd8b-c060c7a54415%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea

[Bruno Ribeiro da Silva]

Guys,

Thanks for the feedback. My initial thought was to have a more complete
approach to this problem, there is always the case that the admin who is
creating the user doesn't know the person's full name and/or what to use
for username.

This is the flow that I had in mind:

- Admin goes to user list page
- Next to the "ADD USER +" button we would have an "INVITE NEW USER" button
- At the invite page the admin would only have to insert the person's email
address. Optionally he could check if this new user would be a super user
and/or staff.
- At the invitation (link sent by email) page the user would be able to
fill the rest of the information, like: username, first name, last name and
password.

I know this approach requires more work but I think it would be nice to
free the admin from the burden of having to fill all necessary information.


2016-11-17 6:44 GMT-02:00 Curtis Maloney :

> My solution to the "initial password problem" is to send a password reset
> token first...
>
> And Django has this built in, handily :)
>
> http://musings.tinbrain.net/blog/2014/sep/21/registration-django-easy-way/
>
> It would be very easy to use the same approach for an "invite"
> registration pattern.
>
> --
> C
>
>
> On 17/11/16 19:38, Aymeric Augustin wrote:
>
>> Hello,
>>
>> On 16 Nov 2016, at 21:22, Anthony King >> > wrote:
>>>
>>> Sending a link to set a password isn't much better.
>>>
>>> The cardinal rule of passwords is “you must be the only person who knows
>> your password”. This means never writing it down anywhere, except in a
>> proper password manager, and never telling it to anyone, *even* your IT
>> staff — to fight social engineering attacks.
>>
>> Sending a password in clear over email means the IT staff is okay with
>> knowing the user's password. Disregarding their own guidelines sets a
>> poor example and reduces their credibility about password management in
>> general.
>>
>> Of course, on most Django websites, someone who can create a staff user
>> can also change the user’s password — it’s rare to give the “create
>> user” but not the “change user” permission. I’m not making a technical
>> argument here, I’m thinking of IT literacy and educating users.
>>
>> Perhaps a way to force a password change on login would be better,
>>> which has more use elsewhere, such as being able to periodically force
>>> password changes
>>>
>>
>> Forcing a password change on login is another interesting idea to solve
>> this problem. That’s what ActiveDirectory has to do, because OSes don’t
>> have the same password reset possibilities that web applications have.
>>
>> However I think that would mean solving the general problem of password
>> rotation. Django solved password validation recently; it could solve
>> password rotation next. (Note that password rotation is controversial
>> because it forces users to choose weak passwords with a basic rotation
>> scheme like putting month number at the end, instead of storing strong
>> random password in a password manager. Trade-offs.)
>>
>> I still think a simple solution hooking into the current password reset
>> mechanism, just with a different email template, could be a quick
>> security win for a lot of Django sites. I’d encourage people to use it
>> if it existed.
>>
>> Best regards,
>>
>> --
>> 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/76AE3F1E
>> -6C00-4E4E-86A7-4E1374FF20AF%40polytechnique.org
>> > E-6C00-4E4E-86A7-4E1374FF20AF%40polytechnique.org?utm_
>> medium=email&utm_source=footer>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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/ms
> gid/django-developers/694f60cb-bcd8-cc32-fd8b-c060c7a54415%40tinbrain.net.
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Bruno Ribeiro da Silva
Python Dev and Homebrewer!

-- 
You received this messag

Re: Feature idea

[Aymeric Augustin]

Hello Bruno,

This is getting quite specific. In that case, I think a third-party, pluggable 
application is a better way to do this.

Best regards,

-- 
Aymeric.

> On 17 Nov 2016, at 13:38, Bruno Ribeiro da Silva  
> wrote:
> 
> Guys,
> 
> Thanks for the feedback. My initial thought was to have a more complete 
> approach to this problem, there is always the case that the admin who is 
> creating the user doesn't know the person's full name and/or what to use for 
> username.
> 
> This is the flow that I had in mind:
> 
> - Admin goes to user list page
> - Next to the "ADD USER +" button we would have an "INVITE NEW USER" button
> - At the invite page the admin would only have to insert the person's email 
> address. Optionally he could check if this new user would be a super user 
> and/or staff.
> - At the invitation (link sent by email) page the user would be able to fill 
> the rest of the information, like: username, first name, last name and 
> password.
> 
> I know this approach requires more work but I think it would be nice to free 
> the admin from the burden of having to fill all necessary information.
> 
> 
> 2016-11-17 6:44 GMT-02:00 Curtis Maloney  >:
> My solution to the "initial password problem" is to send a password reset 
> token first...
> 
> And Django has this built in, handily :)
> 
> http://musings.tinbrain.net/blog/2014/sep/21/registration-django-easy-way/ 
> 
> 
> It would be very easy to use the same approach for an "invite" registration 
> pattern.
> 
> --
> C
> 
> 
> On 17/11/16 19:38, Aymeric Augustin wrote:
> Hello,
> 
> On 16 Nov 2016, at 21:22, Anthony King  
> >> wrote:
> 
> Sending a link to set a password isn't much better.
> 
> The cardinal rule of passwords is “you must be the only person who knows
> your password”. This means never writing it down anywhere, except in a
> proper password manager, and never telling it to anyone, *even* your IT
> staff — to fight social engineering attacks.
> 
> Sending a password in clear over email means the IT staff is okay with
> knowing the user's password. Disregarding their own guidelines sets a
> poor example and reduces their credibility about password management in
> general.
> 
> Of course, on most Django websites, someone who can create a staff user
> can also change the user’s password — it’s rare to give the “create
> user” but not the “change user” permission. I’m not making a technical
> argument here, I’m thinking of IT literacy and educating users.
> 
> Perhaps a way to force a password change on login would be better,
> which has more use elsewhere, such as being able to periodically force
> password changes
> 
> Forcing a password change on login is another interesting idea to solve
> this problem. That’s what ActiveDirectory has to do, because OSes don’t
> have the same password reset possibilities that web applications have.
> 
> However I think that would mean solving the general problem of password
> rotation. Django solved password validation recently; it could solve
> password rotation next. (Note that password rotation is controversial
> because it forces users to choose weak passwords with a basic rotation
> scheme like putting month number at the end, instead of storing strong
> random password in a password manager. Trade-offs.)
> 
> I still think a simple solution hooking into the current password reset
> mechanism, just with a different email template, could be a quick
> security win for a lot of Django sites. I’d encourage people to use it
> if it existed.
> 
> Best regards,
> 
> --
> 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/76AE3F1E-6C00-4E4E-86A7-4E1374FF20AF%40polytechnique.org
>  
> 
>   
> 

Re: #27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

['Tom Evans' via Django developers (Contributions to Django itself)]

On Wed, Nov 16, 2016 at 10:29 PM, Thomas Turner  wrote:
> Hi
>
> The other day I raise a ticket to do with ALLOWED_HOSTS and it was suggested
> that I post on this group before creating a patch
> The ticket is https://code.djangoproject.com/ticket/27485
>
> The problem
>
> Now that Django 1.10.3 forces ALLOWED_HOSTS on with debug I have a problem.
> The problem is that when I developing I use an ip-address range of
> 192.168.1.*.
> The Ip-address can change depending on the computer I use.
> so I required the ability to add wildcard partly in an hostname.
> ie
> ALLOWED_HOSTS = ['192.168.1.*', '.mydomain.com']

Or:
  from socket import gethostname, gethostbyname
  ALLOWED_HOSTS = [ gethostname(), gethostbyname(gethostname()), ]

?

Cheers

Tom

-- 
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/CAFHbX1LndZK4DR7Lvqd3YeOBJoT33PpnGW-Vr84mF%3Ds1zdTQFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

[Thomas Turner]

Thank you all. I will have a look to see if I can do it without patching.

Tom

On Thursday, November 17, 2016 at 12:42:56 AM UTC, Thomas Turner wrote:
>
> Hi
>
> The other day I raise a ticket to do with ALLOWED_HOSTS and it was 
> suggested that I post on this group before creating a patch
> The ticket is https://code.djangoproject.com/ticket/27485
>
> The problem
>
> Now that Django 1.10.3 forces ALLOWED_HOSTS on with debug I have a problem.
> The problem is that when I developing I use an ip-address range of 
> 192.168.1.*. 
> The Ip-address can change depending on the computer I use.
> so I required the ability to add wildcard partly in an hostname.
> ie 
> ALLOWED_HOSTS = ['192.168.1.*', '.mydomain.com']
> I have seen this solution that doesn't require Django to be changed 
> however I don't like it as I feel this could be a security issue
> ​
> http://stackoverflow.com/questions/37031749/django-allowed-hosts-ips-range
>
> I happy to do a patch for this. What do people think?
>
> Tom
>
>
>
>

-- 
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/b5acf0e5-5114-4346-8cd3-75e3946c973d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.