[issue42982] Update suggested number of iterations for pbkdf2_hmac()
April King added the comment: The code snippet still uses 10. Given that many people will simply copy-and-paste without questioning, should we update that too? -- ___ Python tracker <https://bugs.python.org/issue42982> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42982] Update suggested number of iterations for pbkdf2_hmac()
April King added the comment: Django probably stores and computes more passwords than every other Python framework combined, and it doesn't provide you any control over the number of iterations. And it hasn't for years. If this were truly a problem, wouldn't their users be complaining about it constantly? Werkzeug was doing 150,000 iterations as of 0.15.x, released three years ago, and does 260,000 iterations today. Again, no complaints or issues. In practicality, this is almost never a problem - user logins and password changes are extremely rare events compared to all other activity, and so the computation time is essentially irrelevant outside response time for that individual user. No matter how many users, the systems are scaling such that the computation time of that rare event remains a fraction of overall CPU use. -- ___ Python tracker <https://bugs.python.org/issue42982> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42982] Update suggested number of iterations for pbkdf2_hmac()
April King added the comment: Django uses 390,000 iterations as of late 2021, as does the Python Cryptography project. We should be aligned with their recommendations, or at least a good deal closer than we are now. 390,000 actually makes it a conservative recommendation for key derivation, as that number of rounds takes ~133ms to compute on my M1 versus 36ms. Usually you're shooting for ~250ms. Being off by ~50% is probably okay, being off by this much is considerably worse. Anyways, I'd be happy to make such a PR if folks are amenable to it. -- nosy: +april ___ Python tracker <https://bugs.python.org/issue42982> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18617] AIA chasing for missing intermediate certificates on TLS connections
April King added the comment: Err, sorry, I may have been a bit unclear. AIA chasing is not *universal* amongst browsers. IE, Edge, Chrome, and Safari perform AIA chasing. Firefox maintains a cache of intermediate certificate authorities. I noted that a bit further underneath, but my apologies if it was confusing. That said, every browser has a some chosen some underlying method to ameliorate this common TLS error. It would be amazing if Python could similarly resolve this issue for developers. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18617] AIA chasing for missing intermediate certificates on TLS connections
April King added the comment: Browsers universally support AIA chasing/fetching, as do a number of underlying OS libraries, such as Secure Transport (macOS) and schannel (Windows). As a result, it is becoming increasingly common for server operators to fail to include the entire certificate chain in their handshake. By some measures, anywhere from 10 to over 30% of all TLS errors(1) are caused by missing intermediate certificates. There are a handful of ways that scanners and other tools have worked around this issue. Some, like SSL Labs, do their own AIA chasing. Others make subprocess to other tools linked to OS libraries which invisibly perform AIA chasing, such as curl on macOS. Others, like Firefox, maintain a cache of intermediate certificates. In any case, all of these solutions are concession to the reality that TLS is really hard and that it is largely impossible to solve this particular misconfiguration issue. I myself write a popular tool(2) that does scanning of sites for missing security configurations. Although it's not explicitly focused on TLS, some of the underlying tests rely on a verified TLS connection. For example, the HTTP Strict Transport Security (HSTS) header can only be set on valid TLS connections. I use requests (which uses httplib underneath), but I'm unable to tell if a given certificate error is because of either: a) the certificate validation actually failed (for example, due to being expired), or b) there was a missing intermediate certificate and that things would have worked if AIA chasing was available As a result, I have to tell people that their HSTS header can't be set. This is often incorrect, because browsers that do AIA chasing consider the connection perfectly secure for the purposes of HSTS. It would be really nice if Python's httplib could be updated to do transparent AIA chasing, with the optional ability to turn it off. In an ideal world, the underlying TLS libraries (such as OpenSSL) would do this for us, but unfortunately as things stand now OpenSSL leaves it up to the applications themselves to perform chasing. According to Mozilla research (3), if implemented, it would reduce TLS errors by approximately 6% were AIA chasing always performed and successful. Thanks! 1. https://docs.google.com/document/d/1ryqFMSHHRDERg1jm3LeVt7VMfxtXXrI8p49gmtniNP0/edit?pli=1 2. https://observatory.mozilla.org/ 3. https://bugzilla.mozilla.org/show_bug.cgi?id=399324#c80 -- nosy: +april title: TLS and Intermediate Certificates -> AIA chasing for missing intermediate certificates on TLS connections ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
