The page does not recommend them directly, but also doesn't discourage them. In fact, it requires "guidance", which IMO might as well be a strength indicator.
> Verifiers SHALL offer guidance to the subscriber to assist the user in choosing a strong password
Reading through their guidance they don't really mention anything about password strength indicators being a good or bad idea. Sure, they list out a set of rules to verify passwords by and state no OTHER arbitrary rules should be included. But that doesn't prevent you from calculating password strength based on the rules they specify ie. minimum length and complexity.
But I get that "strength" is a poor metric. It shouldn't allow "weak" passwords. It should be binary - pass or fail.
The nicest thing about strength indicators - and I reckon this is why they are copied a lot - is that they are usually real-time feedback to the user with a nice red/orange/green invalid/weak/strong indicator that updates as the user types. The best ones even go as far as show you the list of rules your password is failing to meet, again updating as you type. Much much nicer than the server-side validation form submission loop imo.
So, remove the middle concept of "weak but allowed" passwords from the strength indicator widget, I think then you get good UX that meets NIST recommendations..?
The most common reason I get, professionally, is that it "prevents scripting" ... as if hackers are both using Chrome extensions at scale but also can't figure out how to defeat javascript and html form restrictions.
NIST does not recommend password strength indicators. Make sure the form is compatible with password managers.
https://pages.nist.gov/800-63-4/sp800-63b.html#password
reply