It's time to decide how much to bump the iterations for Django 2.1 --
anyone care to make a proposal? My understanding is that we should revisit
the current "bump by 20% each release" guideline in Django's release
checklist. Django 2.0 uses 100,000 iterations.
On Sunday, February 12, 2017 at 1:
If anyone is still following this thread... =)
I've just updated the Google sheet above with significant changes. I was
using the wrong values for PBKDF2-HMAC-SHA256 hash performance. I now have
up-to-date hw costs and new evidence in play. Definitely worth having a
look at the latest version.
*IMPORTANT NOTICE:* I've just made an important change to the Google Docs
Sheet here:
https://docs.google.com/spreadsheets/d/16_KdYAW03sb86-w_AFFnM79IaTWQ7Ugx4T0VMfGteTM/edit?usp=sharing
Realizing that most security policies make requirements such as "At least 1
character must be a numeral", et
W dniu poniedziałek, 16 stycznia 2017 18:55:25 UTC+1 użytkownik Martin
Koistinen napisał:
>
> Also, if a developer is experienced/motivated enough to *lower* the hash
> iterations, s/he'll be more likely to also be experienced/motivated enough
> to put other controls in place to compensate.
>
O
Updated the sheet with more recent GPU pricing.
On Thursday, January 19, 2017 at 1:19:57 PM UTC-5, Martin Koistinen wrote:
>
> All, I've converted my worksheet into a Google Docs Sheet here:
> https://docs.google.com/spreadsheets/d/16_KdYAW03sb86-w_AFFnM79IaTWQ7Ugx4T0VMfGteTM/edit?usp=sharing
>
>
All, I've converted my worksheet into a Google Docs Sheet
here:
https://docs.google.com/spreadsheets/d/16_KdYAW03sb86-w_AFFnM79IaTWQ7Ugx4T0VMfGteTM/edit?usp=sharing
Note that it isn't really editable here. You'll need to make a copy into
your own account or download into a local spreadsheet to
Tim, I've sent you a model I've assembled recently for your review. I'll
work towards making it more user-friendly (I.e., NOT in Apple Numbers
format) and share it here for the whole community.
But for here and now, I would at the very least assume that the cost of a
brute-force attack on passw
I increased the iterations to 100,000 on master (targeting Django 2.0). It
would be nice to determine a guideline for how to determine future
increases.
On Monday, January 16, 2017 at 12:55:25 PM UTC-5, Martin Koistinen wrote:
>
> Tobias,
>
> Thanks for the comprehensive benchmarking and summary
Tobias,
Thanks for the comprehensive benchmarking and summary of the situation! I
agree on all points, but I'd like to add, that we should err on the side of
high iterations for the simple fact that most developers would sooner
accept the risk of a DoS long before the risk of compromised user a
I'm not sure the DoS concern is really something that can be addressed
here. Regardless of the number of iterations we choose, POSTing to the
login form will always be a target, unless it's appropriately protected
(i.e., with some combination of rate limiting, recaptcha, and/or something
at the net
I agree. The question in my mind is how to pick an appropriate number of
iterations that we don't risk causing a DoS on (at least most) existing
sites due to increased CPU usage. Or at least, can we offer some
suggestions about how to tell if your site receives sufficient traffic that
you might
IMO this doesn't change the argument that it would be best to default to
the higher number of iterations (i.e., 100k or higher, given some time as
passed since 2013), while noting in the documentation that individual
projects have the ability to reduce it if need be (though perhaps
recommending tha
The Python3.5 on my system was installed by the official Python installer,
and is almost 3X slower than the Apple-built 2.7 install. I use pip all day
long.
True, my MacBook is not a server, but it still serves to demonstrate the
point that it is not a reasonable assumption that all 3.5 install
That's a correct assumption -- you won't be able to use pip without OpenSSL.
Alex
On Mon, Jan 9, 2017 at 7:39 PM, Tim Graham wrote:
> About "we cannot just assume that all Python 3 installs have a "fast"
> PBKDF2 implementation" -- I'd expect very few if any Django users to be
> compiling their
About "we cannot just assume that all Python 3 installs have a "fast"
PBKDF2 implementation" -- I'd expect very few if any Django users to be
compiling their own Python and doing so without OpenSSL. I'm guessing that
any operating system Python will have the OpenSSL bindings. Or is that a
bad a
Slightly off-topic, this presents a really nice case for switching to
Argon2 via argon2_cffi (supported in Django 1.10+). Its super fast (C-lib)
and resistant to GPU/ASIC brute-forcing. So, where as an attacker's 8-GPU
hashing machine would probably have something on the order of 24,000X more
h
If anyone is curious about the breakdown of versions, I used the following
query:
SELECT
REGEXP_EXTRACT(details.python, r"^([^\.]+\.[^\.]+\.[^\.]+)") as
python_version,
COUNT(*) as download_count,
FROM
TABLE_DATE_RANGE(
[the-psf:pypi.downloads],
DATE_ADD(CURRENT_TIMESTAMP(), -2, "wee
I think this is a pretty solid guess. Bear in mind this was a direct
install from Python.org.
The important thing here is, this demonstrates that we cannot just assume
that all Python 3 installs have a "fast" PBKDF2 implementation =/
On Wednesday, January 4, 2017 at 11:33:17 AM UTC-5, Tobias Mc
Okay, for good measure, here's with 2.7.7. And yeah, looks like almost 4x
slower.
Python: 2.7.7, Django: 1.10.4
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.3050s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.30
Thanks Alex, TIL
https://mail.python.org/pipermail/distutils-sig/2016-May/028986.html
On 4 January 2017 at 17:42, Alex Gaynor wrote:
> Python 2.7.12 will look the same as 3.5.x, they both have the optimized
> implementation. Only 2.7.X where X<8 will have the slow implementation.
>
> If someone
Python 2.7.12 will look the same as 3.5.x, they both have the optimized
implementation. Only 2.7.X where X<8 will have the slow implementation.
If someone was motivated, they could look at the PyPI bigquery and see what
versions of 2.7 people are using to install django.
Alex
On Wed, Jan 4, 2017
FWIW, here are my own results from that benchmark (I ran each 5 times just
to account for any other system activity):
Python: 2.7.12, Django: 1.10.4
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.0884s
Using cipher: "pbkdf2_sha256" with 100,000 iterations,
Here's an interesting tidbit from Alex Gaynor in 2014:
https://github.com/django/django/commit/6732566967888f2c12efee1146940c85c0154e60#diff-dd9c116fcefaf3916ace2608656311e0
It's worth noting that, if I'm understanding this correctly, there are two
slow versions of pbkdf2 we have to worry about -
Still, this benchmark shows Python 3.5 being 3 times slower than Python 2.7.
This is a surprisingly large regression for this time-sensitive function.
--
Aymeric.
> On 4 Jan 2017, at 02:06, Tim Graham wrote:
>
> The PBKDF2 speed improvements are in Python 2.7.8 and 3.4+, so you'd need to
> u
The PBKDF2 speed improvements are in Python 2.7.8 and 3.4+, so you'd need
to use Python 2.7.7 or earlier to get the slower version.
On Tuesday, January 3, 2017 at 7:56:35 PM UTC-5, Martin Koistinen wrote:
>
> H, I just tried this using a simple management command to do some
> basic benchmark
H, I just tried this using a simple management command to do some basic
benchmarking of password hashing. I made this little package Py2/Py3
compatible. You can find it here:
https://github.com/mkoistinen/hash_benchmark
(Just install it from the repo into an existing project, then add
'has
H, I just tried this using a simple management command to do some basic
benchmarking of password hashing. I made this little package Py2/Py3
compatible. You can find it
here: https://github.com/mkoistinen/hash_benchmark
(Just install it from the repo into an existing project, then add
'has
On Tue, Jan 3, 2017 at 1:14 PM, Adam Johnson wrote:
> But, to be consistent with Django 1.x going forward, let's define 36,000
>> iterations as "acceptable performance" for a Python2 with Django 1.11
>> install on a typical piece of server hardware today (beginning of 2017). A
>> useful benchmark
>
> But, to be consistent with Django 1.x going forward, let's define 36,000
> iterations as "acceptable performance" for a Python2 with Django 1.11
> install on a typical piece of server hardware today (beginning of 2017). A
> useful benchmark would be to determine how many iterations would yield
I think the best practice is to set the iterations as high as you can
tolerate without adversely affecting the user experience as they log-in.
Iteration numbers as high as 200,000 for SHA-256 or even more are not
unheard of these days. Without looking at an application's password
expiration pol
Now that Python 2 is dropped in Django 2.0 and a faster implementation of
pbkdf2 is guaranteed to be available (from what I understand), it's time to
reevaluate our strategy for increasing the number of iterations each
release.
I'm not sure how to evaluate potential performance issues from bump
On 22 sept. 2015, at 21:21, Tim Graham wrote:
> At this point, I'm inclined to continue with the 20-25% iterations increase
> per release methodology we've been using unless someone wants to advocate for
> one of the other proposals.
I agree.
--
Aymeric.
--
You received this message bec
> On 22 sept. 2015, at 19:22, Christophe Pettus wrote:
>
> Given that it is a unidirectional hash, I'm not sure how they *would* be
> rehashed.
If you have password hashed at 15 000 rounds and want 20 000, you do 5 000
rounds on the current hash. (I don’t know if Django does this.)
--
Aymeri
Right -- the performance is only slightly worse during an upgrade than
during other actions. I found the conversation I was thinking about. It's
in the private security tracker (the patch to upgrade the iterations count
was developed there), so I'll copy/paste the relevant bits here. The patch
Sure, but such a problem has nothing to do with password upgrades, it can
already be triggered by registration, or even just logging in without a
password upgrade.
Alex
On Tue, Sep 22, 2015 at 2:43 PM, Tim Graham wrote:
> Sorry, I explained poorly. We do upgrade passwords when the iteration
> c
Sorry, I explained poorly. We do upgrade passwords when the iteration count
is increased
https://docs.djangoproject.com/en/1.8/topics/auth/passwords/#password-upgrading
If we increase the iterations to , when a user logs in, we
have to hash to check the password against the current
hash plus
On Sep 22, 2015, at 10:27 AM, Tim Graham wrote:
> We have access to the plain text password when the user logs in.
Right, so we could *in theory* upgrade the user's password then if we wished
(not clear if we want to). Even so, I don't think that would be a DDoS-attack
level problem, since i
We have access to the plain text password when the user logs in.
On Tuesday, September 22, 2015 at 1:23:01 PM UTC-4, Xof wrote:
>
>
> On Sep 22, 2015, at 10:18 AM, Tim Graham >
> wrote:
>
> > As I understand it, the problem with increasing the number of iterations
> on the slower hasher is that
On Sep 22, 2015, at 10:18 AM, Tim Graham wrote:
> As I understand it, the problem with increasing the number of iterations on
> the slower hasher is that upgrading Django could effectively result in a DDoS
> attack after you upgrade Django as users passwords are upgraded.
Is that correct? My
As I understand it, the problem with increasing the number of iterations on
the slower hasher is that upgrading Django could effectively result in a
DDoS attack after you upgrade Django as users passwords are upgraded.
Some benchmarking suggests that the new algorithm results in a 3x speed up
(
Is the concern that 100,000 iterations is too slow on python < 2.7.8 but is
acceptable on versions after that? If so, then we wouldn't be breaking <
2.7.8, we'd just be reducing the performance profile, right? We could call
out such things in the release notes.
On Tuesday, 22 September 2015 02
On September 21, 2015 at 10:55:57 AM, Collin Anderson (cmawebs...@gmail.com)
wrote:
> Is there an external library for Python < 2.7.8? I know we don't officially
> support the system version of python in RHEL/CentOS and Ubuntu, but I bet
> we could get away with requiring a dependency for those ol
Is there an external library for Python < 2.7.8? I know we don't officially
support the system version of python in RHEL/CentOS and Ubuntu, but I bet
we could get away with requiring a dependency for those old versions of
Python in new versions of Django.
On Mon, Sep 21, 2015 at 10:30 AM, Tim Grah
Django 1.8 is the last version to support Python 3.2 and 3.3, so I believe
we could assume Python 2.7.8+ and 3.4+ as of Django 1.9. While we only
*officially* support the latest release of each Python series, explicitly
dropping support for < Python 2.7.8 might not be acceptable, however, it
se
On September 20, 2015 at 7:26:09 PM, Alex Gaynor (alex.gay...@gmail.com) wrote:
> > Unfortunately 24k iterations is behind where we'd want to be
> (~100k iterations, or a factor of 4, last I checked).
If I remember, a key thing was we wanted the PBKDF2 iterations to be much
higher than they were
Unfortunately here is where we hit an asymmetry: single threaded
performance of PBKDF2 _as realized in our pure Python implementation_
indeed does not improve by 25% every 8 months.
Unfortunately 24k iterations is behind where we'd want to be (~100k
iterations, or a factor of 4, last I checked).
46 matches
Mail list logo
