First, it's not either-or. You can match against zxcvbn strength and some passwordlist.
Second, think of the output of zxcvbn as a very weak hash with a low collision rate. E.g. 'correct-battery-horse-staple' maps to an estimated 213811968952000000000 guesses. In addition to being potentially algorithmically reversible, attackers can simply perform an offline attack against the value 213811968952000000000. So, this metric should never be exposed (e.g. in log files, on screen, etc.)
Third, having the estimated entropy helps a lot when password cracking. If you have the password hash digest and the zxcvbn metrics, then it makes the cracker's job much easier by reducing the search space. (Think, going from checking each molecule of an apple to checking only each molecule on the peel of an apple.)
Further, it's not perfect. The zxcvbn library I used suggests 'correct-battery-horse-staple' is a very strong password!
Yes, I'm very very familiar with this :) I stand by my assertion, "correct-horse-battery-staple" is a weak password to use today. Zxcvbn reporting it as secure is an example of where it's weak.
That XKCD comic came out August 2011, and this article was released April 2012, eight months later. At the time, it made sense to use that as an example of a "highly entropic password" in a blogpost targeting a general technical audience.
It has now been 156.5 months since that comic was released, and 164.5 since zxcvbn was originally trained on its 2011 dataset. "Correct-horse-battery-staple" and its variations are widely used strings and is no longer an example of a strong password.
It's worth being careful about our definition of entropy. The same highly-entropic source generates "hunter2" just as often as it generates "aaaaaaa" just as often as it generates "jpnj6i3".
A "good password" is one that is unlikely to be guessed by an offline cracker. But there are countless strategies an attacker might choose, most of which involve taking a list of passwords and applying rules to them. This is why a highly-entropic source is important (e.g. of all the 32-character passwords, 'weak' ones like "aaaaa..." make a negligible percentage of them) as well as uniqueness ("mP7t6e8TAH..." is a weak password the moment it's leaked in a breach.)
You can't know what strategy the attacker will pick beforehand-- the idea is that it's negligibly likely that an attacker chooses a strategy that cracks your password in a few guesses.
Zxcvbn intentionally takes compromises to be a performant best-effort estimation of how many guesses an attacker would take for your password. (It would improve its estimation of guesses by actually trying to guess your password with `hashcat` and the antipublic combolist, or whatever people are using nowadays, but then it would take eons to provide an estimation rather than milliseconds.)
8 chars is not sufficient. The Hive strength estimates switched to Bcrypt this year but there are still weak systems out there and you should set passwords assuming MD5 which currently demands at least 12 chars for typical users.
The theory that stacks are better than registers for an interpreter was pretty conclusively disproven by the Lua 5.0 interpreter. See https://www.lua.org/doc/jucs05.pdf (summary: although decode is slightly more expensive per opcode, you have half as many opcodes to decode on average because you get rid of all the stack manipulation instructions)
... and IIRC this list is no longer sufficient; you need to add to it in order to compile with the current Windows SDK. (Upon closer inspection, it was updated two weeks ago, so maybe it's fine... until the next Windows SDK update.)
I'll admit that this happens less often on Linux, where the system headers are smaller (and everybody uses X11 so there's historic reason to avoid all the short names that were gobbled up by Xlib in the '80s), but I've still run into occasional clashes between different library headers, or between legacy code and updated headers. eg. bool/Bool/BOOL are common collisions among pre-C99 libraries (including libraries that require C99 but don't remove the old names for backwards compatibility reasons), as well as min/MIN/max/MAX which still aren't in standard C as far as I can tell.
The headaches it gives are real, but not large in the grand scheme of things. The lack of defer (or otherwise standardized and cross-platform __attribute__(cleanup) ) is a bigger headache, for example.
"Battery powered coffee grinder" but worse: "battery powered drill, but with Li instead of NiMH" Milwaukee Tool v. Snap On (lots of commentary, here's one example: https://www.youtube.com/watch?v=Y9CLvU5-FRo )
On the software side, AFAIK the infamous "One Click" patent was never held up in court, but companies had to spend significant money defending against lawsuits based on it (and therefore the only possible victory was pyrrhic).
I think the successor Robot Odyssey (https://en.wikipedia.org/wiki/Robot_Odyssey) was much more impressive. Same digital logic was used to control robots and solve physical puzzles.
I'm not able to find the methodology for the w3techs report, but I suspect they only count the ultimate root, not any intermediates.
Let's Encrypt's root is not trusted by any browser yet, so they got a cross-signature from IdenTrust. So far, basically everybody using Let's Encrypt chains to the IdenTrust root.
Given that IdenTrust grew from "<0.1%" to 5.6% since the launch of Let's Encrypt, and the shape is roughly the same as https://letsencrypt.org/stats/ , I strongly suspect that the 5.6% market share credited to IdenTrust actually belongs to Let's Encrypt.
As a check, we can divide 2/3 of the total unexpired Let's Encrypt certificates (~2.8M as of last week, 2/3 because standard practise is to renew a 90 day cert after 60 days, so 1/3 are probably overlapping = 1.86M) by the total number of https sites (I had a hard time finding this, but http://arstechnica.com/security/2016/03/more-than-13-million... claims that 5.9M is 17% of https servers, so 34.7M), and we get 5.4%, which is almost the same number as the IdenTrust number above.
That's still nowhere near Comodo, but it's not completely insignificant.
"Given that IdenTrust grew from "<0.1%" to 5.6% since the launch of Let's Encrypt, and the shape is roughly the same as https://letsencrypt.org/stats/ , I strongly suspect that the 5.6% market share credited to IdenTrust actually belongs to Let's Encrypt."
indent(1) is not idempotent, at least not in the configuration I tested, which makes it practically useless as an editor save hook or an SCM pre-commit hook.
Of all the C pretty-printers I tried (about a year ago), clang-format came closest but none were idempotent on the codebase I threw at it.
go fmt is idempotent, which means I use it in an editor save hook. I got used to the convenience, so now I miss an automatic formatter when writing other languages.
Basically, 8 characters or more, but prevent the user from picking a password that appears on any of the leaked password lists. Store in pbkdf2 or better; use argon2id per https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
That's it. Simple. No mandatory symbols. No mandatory changes after a period of time. A password strength estimation meter is optional.
If it needs to be more secure, I might require more minimum characters, but no other restrictions.