Luke,
thanks for the long explanation. I see your points here. I actually
saw the make token function and was thinking about it what is the best
way to do with that. I think most people here feel there's need to at
least allow some flexibility for the time out since there will be
cases under a day is needed.
I will keep this discussion for a couple of more days to see if we can
get consensus and how we should implemented if needed.
Zach
On Friday, September 22, 2017 at 3:04:01 PM UTC-4, Luke Plant wrote:
I would be +1 to what Adam wrote from me i.e. just allow the value
to accept floats.
However, I don't think it will work due to the way that we round
the precision of timestamps to days
<https://github.com/django/django/blob/master/django/contrib/auth/tokens.py#L21>.
This was done partly to reduce the number of characters needed to
express the timestamp, to keep URLs as short as possible. We would
have to change the mechanism to store more precision into the
timestamp. This would result in an upgrade 'bump' for users (i.e.
links generated before the upgrade would become invalid after
upgrade).
However, I really question whether we need any change here, and
whether it would be a good idea.
Having a short expiration time (less than 1 hour) could cause
major problems for some people - plenty of systems introduce 5 or
10 minute delays in mail delivery, and with some people's internet
connection it can take several minutes to open a web page. This
also means that some people end up finishing the process of
whatever they were doing the next day (I know I've done this
several times on various sites), so a timeout of at least 1 or 2
days is a good default. If you want to come back after the weekend
and carry on, 3 days makes more sense as a minimum.
In terms of security, I don't think there is really any need for
anyone to reduce below the default at all (see below). So I'm very
unconvinced about the need for changing to PASSWORD_RESET_TIMEOUT
- it is just unnecessary upgrade work for some existing projects
(this is the biggest consideration for me), and it could encourage
people to set the value to something low that would decrease
usability.
*Security:*
The security of the password reset feature is almost entirely
independent of the value of the timeout setting. There are 3
attack vectors I can see:
1) Someone's email account is compromised, and they then do a
password reset on a Django site.
We simply can't protect against this AFAICS.
2) Someone's email account is compromised, and they find/use a
password reset email in the person's inbox.
This is the only scenario for which having a shorter timeout makes
a difference. It is somewhat unlikely, because in 99% of cases the
attacker would be able to generate a password reset email
themselves after compromising the account. For this narrow case
where the attacker is unwilling/unable to trigger/receive a new
password reset email, it is worth having some protection against
them being able to use old tokens, but 3 days seems plenty short
enough for this situation, especially given the fact that a *used*
password reset token immediately becomes invalid due to the way we
hash on internal state of the user record.
3) A brute force attack.
To do this, the attacker has to:
1. Supply a user ID (let's assume this is easy)
2. ***Choose*** a timestamp (very easy, just choose the current time)
3. Create a 20 character hexadecimal hmac that matches both the
timestamp and the internal state of the user (see
https://github.com/django/django/blob/master/django/contrib/auth/tokens.py
<https://github.com/django/django/blob/master/django/contrib/auth/tokens.py>
).
Since the attacker can choose the timestamp, the probability of
guessing correctly depends **only** on:
1. The number of bits in the hash (20*4 = 80)
2. The number of attempts (or, the number of requests per second
possible and the time available)
It does **not** depend on the value of the reset timeout **at all**.
If we assume they can make 100 req/s, and they try continuously
for 10 years, they've got a chance of around 1 in 10^13.
In other words, I reject the premise of the ticket, which is that
to improve security some people need to reduce the timeout. It
makes virtually no difference to the security of this feature, and
in fact you would be protected against almost all realistic
attacks if there was no timeout. I imagine that the requirement of
"meeting security requirements" mentioned on the ticket is due to
people who think this works like a short, 6 digit OTP, for which 3
days would be far too long ( see
https://sakurity.com/blog/2015/07/18/2fa.html
<https://sakurity.com/blog/2015/07/18/2fa.html> ). We could put a
note in the docs about this, I don't know how to do that in a
succinct way apart from to link to a copy of this email or something.
However, if we really do 'need' this change, we should at least
keep the default to what it is now, and put a notice in the docs
saying that reducing it hurts usability and makes no practical
difference to security. Since we would be causing an upgrade bump
and breaking existing links, we may as well also switch to
TimestampSigner (the password reset code was originally written
before that existed), which would also mean changing urlconfs I
imagine. This would also require a significant section in the
upgrade notes. (In my book, this is a further argument against
doing this change at all).
Regards,
Luke
On 21/09/17 12:25, Adam Johnson wrote:
Why not just keep PASSWORD_RESET_TIMEOUT_DAYSand allow floats?
Then you can just do 1/24 for an hour.
On 21 September 2017 at 09:50, Eddy C <coupo...@chicheng.me
<javascript:>> wrote:
I think Minute, with default value 30 or 60, is the best unit
for this setting.
3 minutes (even 1) is short enough for edge case and 720 (12
hours) also looks good.
On Thursday, September 21, 2017 at 6:22:20 PM UTC+10, Tom
Forbes wrote:
I think we shouldn't shoe-horn a timedelta into the
existing setting, so my vote is with the second option,
but I think a timedelta is much more readable than just
an integer.
Also, the existing 3 day timeout for password links is
quite surprising from a security point of view. The
consultants I work with would flag up a token that lasts
longer than 12 hours as an issue during a pentest.
IMO a new, far shorter default should be added to this
setting.
On 21 Sep 2017 03:56, "Zhiqiang Liu" <zachl...@gmail.com>
wrote:
I need general consensus on how to proceed with
supporting password expire time to be under a day.
Currently it is not possible because we use
PASSWORD_RESET_TIMEOUT_DAYS.
In ticket 28622
<https://code.djangoproject.com/ticket/28622> we have
two options.
One is to continue to use the same setting
PASSWORD_RESET_TIMEOUT_DAYS, but change the value to
non-integer (such as timedelta) so we can send hours,
minutes, etc to it.
The other one is to create a new setting like
PASSWORD_RESET_TIMEOUT which takes seconds.To support
backward compatibility, I think we should keep
PASSWORD_RESET_TIMEOUT_DAYS and its default value of
3. Only use PASSWORD_RESET_TIMEOUT when provided.
I'm unsure which one is better, so inputs are welcome.
--
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 post to this group, send email to
django-d...@googlegroups.com.
Visit this group at
https://groups.google.com/group/django-developers
<https://groups.google.com/group/django-developers>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/c8e96008-eb95-4924-8e5e-9b02d6b90c99%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/c8e96008-eb95-4924-8e5e-9b02d6b90c99%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit
https://groups.google.com/d/optout
<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-develop...@googlegroups.com
<javascript:>.
To post to this group, send email to
django-d...@googlegroups.com <javascript:>.
Visit this group at
https://groups.google.com/group/django-developers
<https://groups.google.com/group/django-developers>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/6d0d4251-64bc-40a0-b191-9cf3dfe8c91b%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/6d0d4251-64bc-40a0-b191-9cf3dfe8c91b%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
Adam
--
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 <javascript:>.
To post to this group, send email to django-d...@googlegroups.com
<javascript:>.
Visit this group at
https://groups.google.com/group/django-developers
<https://groups.google.com/group/django-developers>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyDDM2Y-krvLkKwxvNp%3DEuLa-oMDhuB%2BkxABwE5Ae76LOPPdw%40mail.gmail.com
<https://groups.google.com/d/msgid/django-developers/CAMyDDM2Y-krvLkKwxvNp%3DEuLa-oMDhuB%2BkxABwE5Ae76LOPPdw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout
<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
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to
django-developers@googlegroups.com
<mailto: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/d82d874b-a076-44ee-a091-ee3924570053%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/d82d874b-a076-44ee-a091-ee3924570053%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
