Hi Marc, To be clear, I think we shouldn't make Argon2 the default just yet. I would rather add it as an option for now and make it the default in a later release. However, I would like to discuss what would block making Argon2 the default already.
> It is once per user, but it's once for *EVERY* user when that scenario > occurs. That could easily bring a site down if sessions were invalidated or > you have short session times. It's far too likely someone will have > serious, hard to debug problems as a result of this magical behaviour. This is indeed a corcern for big websites. What if we make the sudden absense of a C-argon2 a hard error which includes instructions to enable the fallback behavior I described? (To be clear: the absense of C-argon2 would only be an error if it has actually been used as a password hash --- not if it has never been used.) > There's an argument for updating the default project template for new > projects, but that would make setup for new users a lot harder so I don't > really like that idea either. How is this different than making Argon2 the default? Why would the setup be harder? > I also strongly agree with Carl's comment on the PR: Automatic changes in > behaviour based only on the presence or absence of a third-party package > (or C bindings) are questionable in general. Would bundling argon2-cffi with Django be an option? > We can (and by the sounds of > it should) recommend this hasher strongly, but I don't think we need to > make it the default. Unlike SHA256, PBKDF2 isn't a BAD choice yet, it's > just not the best available. I agree, PBKDF2 is not a bad choice if there is a proper password policy in place. I also do not want to suggest there is an immediate problem. Maybe it is helpful to look at a real-world example. On this site[1] two huge sets (the "GMail" and the "10 million" set) are analyzed. The average entropy of these passords appears to be 21.6 bits. At the moment, Django's PBKDF2 uses 60,000 iterations of SHA256. The ASIC "AntMiner S7" computes 4000 million SHA-256 per Joule. Thus a similar ASIC for PBKDF2 would be able to compute ~2^37 PBKDF2's per kWh. Thus, breaking a single 37 bit PBKDF2 would set you back $0.12 (if you have already such an ASIC). Ok, not every attacker has the budget to develop ASICs. Suppose our average Joe attacker has just a GPU. According to [2] a cheap AMD7750 gives you 2.66 million SHA-256 per Joule. That ~2^27 PBKDF2s for $0.12. Our average 21.6 bit password is cheap to break using PBKDF2. On my i7-4790 Django's PBKDF2 takes 75ms. If we pick parameters for Argon2 such that it also takes 75ms to compute, it will compute 0.3 argon2 per Joule. That ~2^20 Argon2 for $0.12. (To be fair, probably some Atom will be more efficient for this than an i7.) So even Argon2 won't prevent the average password to be cheaply cracked. If you follow XKCD's advice and use a "correct horse battery staple" password of 44 bits, then cracking it will cost (as above) if hashed with PBKDF2 and cracked with that ASIC $15.36 if hashed with PBKDF2 and cracked with that GPU $15728 if hashed with Argon2 and cracked with my i7 $2013265 (Even though Argon2 is designed to be hard to compute for ASICs, they might still do a better job than a general purpose CPU: the difference above might be smaller.) Best, Bas [1] http://wpengine.com/unmasked/ [2] https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison -- 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/20160129173007.GB23905%40vinnana.westerbaan.name. For more options, visit https://groups.google.com/d/optout.
