So what's the proposal, switching to requiring a different length when a unicode character is present? How do you know from what set of possible values (like thousands of possible unicode chars versus a-z) the user chose each character?
While 68 bits entropy are secure in a case of good hashing, I think the statement is misleading. Anyone who uses a random generator will just use 16+ random alphanumerics (optionally with symbols) and call it a day; users aren't going to be able to input a unicode snowman with combination marker with orange skin on every keyboard without using the clipboard or other software. It's not more secure, it's just asking for trouble. A software tester can do this, but there is no practical reason to lower the length requirement to 4 characters because an ẍ might be entered.
The author doesn't end up proposing such a thing, but the argument in this paragraph still doesn't sound practical to me.
I think the argument, aimed at the people making the website/app (but not the login, which should be a third party), is that they should ditch ad-hoc and ill-advised password constraints and instead go with a well vetted third party lib that just measures password "strength".
A variant of "don't roll your own crypto (unless you work in the crypto space)".
While 68 bits entropy are secure in a case of good hashing, I think the statement is misleading. Anyone who uses a random generator will just use 16+ random alphanumerics (optionally with symbols) and call it a day; users aren't going to be able to input a unicode snowman with combination marker with orange skin on every keyboard without using the clipboard or other software. It's not more secure, it's just asking for trouble. A software tester can do this, but there is no practical reason to lower the length requirement to 4 characters because an ẍ might be entered.
The author doesn't end up proposing such a thing, but the argument in this paragraph still doesn't sound practical to me.