We already committed a fix for pbkdf2, the DOS vector no longer exists (at
least not in this form):
https://github.com/django/django/commit/68540fe4df44492571bc610a0a043d3d02b3d320
On Thursday, October 3, 2013 9:56:14 AM UTC+2, Ram Rachum wrote:
>
> Hi everybody,
>
> I've submitted the patch,
Hi everybody,
I've submitted the patch, and corrected it, and it's been sitting on the
issue tracker for 2 weeks without anyone commenting. Does anyone care to
discuss this? I want to have this merged in, or discuss any problems in
merging it in.
On Sun, Sep 15, 2013 at 11:27 PM, Ram Rachum wro
Hi,
there are a few things which worry me about this patch (aside from the note
from charettes). You write "and the DoS attack vector is avoided" which is
not true, hashing functions are by design CPU-intensive so you are not
avoiding DoS, even if hashing now consistently takes less (for short
Submitted patch:
https://code.djangoproject.com/ticket/21105#comment:1
On Sunday, September 15, 2013 10:09:55 PM UTC+3, Donald Stufft wrote:
>
>
> On Sep 15, 2013, at 2:59 PM, Florian Apolloner
> >
> wrote:
>
> Hi Ram,
>
> On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote:
>>
>>
On Sep 15, 2013, at 2:59 PM, Florian Apolloner wrote:
> Hi Ram,
>
> On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote:
> Florian, I'm not sure that you read my message carefully enough. I'm not
> proposing to reduce the time that PBKDF2 takes to hash.
>
> By replacing the pas
Hi Ram,
On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote:
>
> Florian, I'm not sure that you read my message carefully enough. I'm *not
> *proposing to reduce the time that PBKDF2 takes to hash.
>
By replacing the password with a hash before running it through PBKDF2 you
are r
We'd want to use SHA256 but that's an OK thing to do AFAIK. I wouldn't agree to
it in a security patch because it breaks backwards compatibility in a much
larger way than the patch we did does.
In fact we already do this with the bcrypt hasher in Django 1.6+ to solve a
password truncation issue
Florian, I'm not sure that you read my message carefully enough. I'm *not
*proposing
to reduce the time that PBKDF2 takes to hash. I'm proposing to keep that
time just as long, but make it independent on the password length.
On Sunday, September 15, 2013 1:12:31 PM UTC+3, Florian Apolloner wrot
On Sunday, September 15, 2013 11:45:29 AM UTC+2, Ram Rachum wrote:
> What if instead of calculating the PBKDF2 hash of the password, we'll
> calculate the PBKDF2 hash of its SHA1 hash? Then the time of checking
> passwords wouldn't depend on their length, and we wouldn't even have to
> place
Thanks Curtis!
I thought about my idea and realized it makes a brute-force attack easier,
and we'd have to make the hashing stronger to compensate... Making the
computation time longer for the real users logging in... So yeah, it won't
help.
But then I had another idea. So PBKDF2 takes a longe
Actually, you'd just speed up their attack, since most failed attempts
would be quicker than others.
If you look in the crypto utils, you'll see a "constant time compare" ...
this is a common thing in crypto circles to avoid leaking "how close" the
guess was by how quickly the mismatch was found.
Hi guys,
I just saw the new release announcement and I had an idea.
What if, in addition to sorting the hard to compute hash for every password, we
will also store the sha 1 hash of the first 5 characters ofthe password's sha1
hash? Wouldn't this allow us to quickly rule out 99% of passwords, t
12 matches
Mail list logo