Hacker News new | ask | show | jobs
by biotech 3151 days ago
> How is this different from websites that think it's okay to force you to abide by ridiculous password restrictions

The difference is that disabling of "autocomplete" is a user interface issue, and can be addressed by the browser I use. The problem of ridiculous password restrictions is not usually something that can be controlled by the client.

I like the idea of convincing IT to change crazy password policies, but I don't have the mental energy to navigate these huge bureaucracies.

3 comments

You don't necessarily have to convince IT. If you instead convince their legal department that by not following the NIST standards for passwords they are opening their company to a lawsuit, that could get results a lot faster.

When IT is convinced they have to decide when to put it into the budget. If they think their policy is not okay, just not perfect the fix will probably be buried in the bottom of the budget pile and cut every year.

When a company does not follow a NIST standard [that applies] that is admissible in court against them. While it isn't an automatic loss they have to defend why they didn't follow the standard. In some cases the defense is not to the jury, but the the judge while can make a "statement of fact" and tell the jury to assume negligence for not following the standards. When legal says the cost of not complying with NIST password guidelines is potentially 10 million dollars that puts fixing the password requirements much higher in the budget.

The relevant bit being "Verifiers SHOULD permit claimants to use 'paste' functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets."

But that's a recent change to the NIST guidance. Searching for "Bill Burr NIST" will turn up recent stories about the original author's regret of a lot of the password recommendations from the original publication in 2003 that survived until the update this year.

Do you have any references to instances where this strategy was successful?
No, it is an idea. The NIST standard is new enough that I wouldn't expect anything yet. Going to court takes years.IF they settle out of court they probably make not talking a part of the settlement.
Not all websites are operated by US companies. Would that still work for, say UBS (a big bank) in Switzerland?
NIST is recognized worldwide in a similar vein to the IEEE, IETF or ISO. It's a regulation organization important enough to get to move banks, large companies and outsourcing firms.

A recommendation won't allow you to sue a company contrary to what the other commenters seem to think, but it's enough for any internal employee who works on something to call for and justify a change.

You can sue anyone for anything. Winning is different matter. Even if you can't win though, the cost of defending a trial is expensive.
Maybe, does UBS have a branch in the US that you can sue? Alternatively, does the country you are in treat foreign standards as admissible in their court in some form? Does the country have their own version of NIST that is willing to "leverage" the work of another country into their own standards, thus making the NIST standard a national standard for their country? Does the country have their own version of NIST that has already issued a standard? Any of the above are angles to consider before you reject legal approaches to the problem just because the country doens't apply.

Your question is one of the reasons I didn't say the legal route was a better way. It is an option that may get better results in some cases. Even in the US it may not always get the best result.

I'm all for allowing the user to control whether autocomplete is or isn't respected. But the browser breaking web standards to force certain choices on the user is about the worst possible way to go about this.
Aren't cookies a web standard? I can assure you that Safari's policies w.r.t. cookies "break" a lot of website functionality, and quite intentionally so. You may not like that functionality, but the website marketers like it and have spent lots of time implementing it.

So - what's ok to break, and what isn't? In the end, it's a judgement call on the browser developer. I like what another person said here - the browser is an "user agent", as long as the actions are clearly motivated by user interest, I think they're ok even if/when they break some standards.

> So - what's ok to break, and what isn't?

I'd say, for a start, achieving consensus before breaking is ideal. If the attempt to achieve consensus fails, at least I can see they tried (or I can disagree). Hopefully in the future users can use their leverage to make it not a judgement call on the browser developer, but a judgement call by the community of users. The myriad of features in browsers, however, makes it a difficult arena to enter making a large swath of users subject to these judgement calls.

> as long as the actions are clearly motivated by user interest

It doesn't matter what the road is paved with. Many things are not clear and intent is also not clear. You should not use intent to determine what you are ok with, you should use the action and effect. You may be ok with Safari's approach to third party cookies, or Chrome's approach to cookies, which is ok. But you might not be ok with the next action, and when it hurts you as a user, the reasoning will matter less than it does when you support it.

They do have a consensus about these things among their users. Virtually no one wants their password manager to not work or for third-party marketers to be able to track them more easily.

The people who disagree are third-parties who want to impose their own preferences on Chrome's users. Their opinions should not be taken into account because they are not Chrome's users.

I am a Chrome user, I totally agree that the browser should fill the password for me and not accept third party cookies. And yet I don't want the fields in my intranet app to be filled with garbage.
We get regular complaints from users using chrome about password autofill where they didn't want it. It would be really nice if chrome would honor standards and let us worry about how to make our users lives better.
Give the user control. Breaking behaviour that the user might rely on, is not acting in the interest of the user. If you think it's better to block certain behaviour, at least tell the user and allow them to override your default.
Except in this case they're breaking forms that disable autocomplete for legitimate reasons.

If there is never a valid reason to disable autocomplete and therefore "the standard is wrong", there are ways to change the standard. The standardisation process for Web APIs actively involves browser vendors but allows for building a consensus before jumping the gun.