This sounded like clickbait when reading the first bit (SHA1+iterations isn't that bad, as the SHA1 vuln doesn't affect password hashing), but it turns out the number of iterations is 1. That's not SHA1 "with a low iteration count", that's just plain SHA1. And no salt it seems.
Pretty bad indeed, but then again: this is a master password you're setting. The one password to rule them all ought to be strong anyway. If you do that, it's perfectly safe.
From the article, the password is salted at least:
"I eventually found the sftkdb_passwordToKey() function that converts a [website] password into an encryption key by means of applying SHA-1 hashing to a string consisting of a random salt and your actual master password."
Passwords with 128bit of entropy have always been and will for the foreseeable future be secure with any password hashing algorithm that is not completely broken (i.e. uses a cryptographic hash function and a seed). 28 random alphanumeric characters fulfill the requirement and are reasonably fast to type, e.g. m7wdgdorhvi3jerzyztc2u642at
> The problem is that each year definition of "strong password" changes
Luckily, you can change your password.
Also, you could say the same thing for the hashing algorithm. Every year you'd want to up your iteration count or even upgrade algos (e.g. use memory-hardness when scrypt was released).
It works both ways, but overestimating is never a bad idea: if someone hacks you now and cracks it in five years, some passwords may still be in use.
I don't think the definition of "strong password" has changed much in the last ten years. The hashing schemes for storing passwords have changed, sure, but I think having sixteen or more characters with numbers, capital letters and symbols has been recommended for years now.
I have not heard anyone argue for requiring >=10 characters (9 is the highest requirement I've ever seen). 12+ I've heard being said as "if you really want to do it properly" in security reports for clients, but we know that'll hardly ever be followed for anything other than high-security places like sysadmins at a bank. I've never heard anyone say 16+, let alone it being the standard recommendation for years.
Most (all?) places that discover that 9+ is not good enough for the most valuable credentials, move to 2FA instead.
Even just //44$random$WORDS$11// is effectively just as safe, in the real world. Especially if you use gibberish words that aren't in any commonly used dictionary.
Honestly, I had a good laugh until I saw who wrote that. To be fair, I think Bruce is saying that most people will fail to pick truly random words, which is fair.
However, as you point out, it provides no argument against passphrases, aside from referring to them as a "trick". I still don't know how people look at the XKCD explanation (where Randall Munroe actually does a pretty good job of correctly and succinctly detailing the strength of the two password styles [1]), and call it a trick. The only trick is that your mind has an easier time remembering passphrases than it does remembering a similar strength random string.
[1] Specifically, Randall already assumes that the cracker knows that the password is a passphrase, and has the 1000-word list it was picked from.
You still definitely have to accept at least four words actuallyrandomlygenerated (this is important, else the scheme falls apart horribly). Accepting 6 random words is pretty secure IMHO.
Pretty bad indeed, but then again: this is a master password you're setting. The one password to rule them all ought to be strong anyway. If you do that, it's perfectly safe.