On Jun 29, 9:42 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Jun 28, 10:01 pm, "Scott Moonen" <[EMAIL PROTECTED]> wrote:
>
> > If you add the timestamp into both the hash and the token then you can
> > achieve a more granular expiration policy.
>
> That's the approach I use for djangopeopl
On Sat, Jun 28, 2008 at 4:48 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On Jun 28, 11:21 pm, Luke Plant <[EMAIL PROTECTED]> wrote:
>> MD5 is 8 chars shorter. Do we really need SHA-1? If I understand
>> correctly, the only known vulnerability with MD5 is the ability to
>> force collisions,
Thanks Simon, for the idea of using a timestamp in the url and in the
hash. A really good idea.
You could shorten the hash to 6 digits by using the HOTP algorithm
(http://www.openauthentication.org/). If we send it in base32 it will
be even shorter. I've got the Python code for HOTP ready and wou
On Jun 28, 11:21 pm, Luke Plant <[EMAIL PROTECTED]> wrote:
> MD5 is 8 chars shorter. Do we really need SHA-1? If I understand
> correctly, the only known vulnerability with MD5 is the ability to
> force collisions, but that will not help an attacker in this case.
> The only thing that an attacker
On Saturday 28 June 2008 21:48:24 Simon Willison wrote:
> A further micro-optimisation is to leave out the hyphen entirely,
> since an SHA-1 hash is always 40 characters long (we should
> probably use that instead of MD5).
MD5 is 8 chars shorter. Do we really need SHA-1? If I understand
corre
On Jun 28, 10:01 pm, "Scott Moonen" <[EMAIL PROTECTED]> wrote:
> If you add the timestamp into both the hash and the token then you can
> achieve a more granular expiration policy.
That's the approach I use for djangopeople.net - the problem is that
including the timestamp lengthens the URL yet f
If you add the timestamp into both the hash and the token then you can
achieve a more granular expiration policy.
E.g., let's say the timestamp is something like '200806282255', indicating
the reset token expires at 10:55pm local time on today's date. You can
generate a token that looks like this
On Jun 28, 12:29 pm, Luke Plant <[EMAIL PROTECTED]> wrote:
> https://example.com/reset/34-7127f83ebf8ce7ed22bdc50a50572a30
>
> i.e.
>
> https://example.com/reset/{uid}-{hash}
I've been playing with this a bit and the one thing that was
concerning me is that the UID on large sites can end up being
On Jun 28, 7:58 pm, "Adi J. Sieker" <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote:
> > That's absolutely ingenious - that approach gets my vote. I think I'll
> > switch DjangoPeople over to that.
>
> and to have the token expire you could add the date of the following day
> into the has
On Sat, 28 Jun 2008 09:18:46 +0200, Simon Willison
<[EMAIL PROTECTED]> wrote:
> That's absolutely ingenious - that approach gets my vote. I think I'll
> switch DjangoPeople over to that.
and to have the token expire you could add the date of the following day
into the hash.
That way the toke
>
> The one slight issue
> is that if the user picks the same password (or ever does so in the
> future) then the hash could become the same again,
>
I don't think that's true, at least using django.contrib.auth. The salt is
re-generated whenever the password is changed, so the odds of the user
p
On Saturday 28 June 2008 01:39:26 Scott Moonen wrote:
> > The problem with this is it requires state on the server, which
> > means . . .
>
> I don't think it's necessary to implement this in such a way that
> additional server state is stored. Instead, you could let the
> confirmation token be
On Jun 28, 1:39 am, "Scott Moonen" <[EMAIL PROTECTED]> wrote:
> I don't think it's necessary to implement this in such a way that additional
> server state is stored. Instead, you could let the confirmation token be a
> hash of the internal user state -- including, most importantly, the user
> pa
On Fri, Jun 27, 2008 at 8:31 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
> I've got code for this lying round which I'd be happy to donate if
> people agree this is the right approach.
I personally much prefer this approach. I've worked in a couple
communities where personal attacks were quite
>
> The problem with this is it requires state on the server, which means . . .
I don't think it's necessary to implement this in such a way that additional
server state is stored. Instead, you could let the confirmation token be a
hash of the internal user state -- including, most importantly,
On Jun 28, 1:12 am, Luke Plant <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] said the following:
> > I'd suggest making the code to change the password a one-use-only
> > item though, so that even if someone did sniff the code, it'd be
> > useless after that.
>
> The problem with this is it req
On Friday 27 June 2008 23:06:57 Collin Grady wrote:
> [EMAIL PROTECTED] said the following:
> I'd suggest making the code to change the password a one-use-only
> item though, so that even if someone did sniff the code, it'd be
> useless after that.
The problem with this is it requires state on th
[EMAIL PROTECTED] said the following:
> It sounds like what you are advocating is changing the password reset
> to work similar to the way activation works in James Bennett's django-
> registration, is that correct?
Similar to that is what it sounds like - I'm definitely +1 on this - a
lot of si
It sounds like what you are advocating is changing the password reset
to work similar to the way activation works in James Bennett's django-
registration, is that correct?
On Jun 27, 4:01 pm, Luke Plant <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Currently password reset is done without any confirma
Hi all,
Currently password reset is done without any confirmation, so all you
have to do is know someone's email and a Django site that they use
(assuming it uses the default password reset code) and you can change
their password. In this way, you only have to make about 1
request/minute to
20 matches
Mail list logo
