Hacker News Reader

Comment by pluma | Hacker News Reader

How is this different from websites that think it's okay to force you to abide by ridiculous password restrictions (e.g. 6-8 characters, must include digits, upper- and lowercase letters, and special characters but no quotation marks or any known SQL keywords)?

The right thing to do is to bring the issue up with whoever is running the website. If they decide not to act on it because they think they know security/UX better than Google/you, they're stuck with crappier security/UX and the market should sort it out.

I've actually managed to convince a company to stop prohibiting copy-paste on logins by pointing them at the new NIST password guidelines. I don't expect this to work for every company, but if they intentionally don't change, it's okay to name and shame them for it. Whether it's a UX sin or security voodoo.

View on HN

> 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.

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.

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.

Not all websites are operated by US companies. Would that still work for, say UBS (a big bank) in Switzerland?

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.

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.

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.

Are these the guidelines you speak of?

https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver

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.

"How is this different from websites that think it's okay to force you to abide by ridiculous password restrictions (e.g. 6-8 characters, must include digits, upper- and lowercase letters, and special characters but no quotation marks or any known SQL keywords)?"

If the Chrome team could figure out a way to force all of those sites to change their password restrictions through a Chrome update, they probably would.

>The right thing to do is to bring the issue up with whoever is running the website

What? No. Clearly it should never have been in the spec, and a browser should be the extension of the users desires.

> a browser should be the extension of the users desires.

In a perfect world that would be the case, because the browser would belong to the user. But how much did you pay for your last browser? Consider yourself lucky when the browser does something you consider beneficial.

The market should sort it out is deeply naive wishful thinking. Numerous sites block copy/paste, block password managers from functioning well, still have password rules from the Pleistocene let alone the most recent NIST recommendations. And those companies are worth more today than 10 years ago. So no, it really doesn't get sorted out. To the market, this is a detail it simply doesn't care about.

Because it is a detail virtually nobody cares about.

How insane would the password rules have to be for anyone to travel 1 hour more to go to a different university? How insane for them to stop playing a given video game? To change banking institutions?

I don't have the answer for others, but for me, the answer to all of those is "pretty insane". Except for the banking case, password security is a minor concern (and even then, the system protects us with anti-fraud laws and what not).

In a sense, the market is sorting itself out: it just decided that it doesn't care much about passwords. In fact, if you figure out a way to be profitable while offering twice the interest rate but every time people log in to your bank they have to dance the robot or whatever, you'd probably still have customers.

Banking institutions follow the NIST regulations, they are already changing.

Browsers preventing this is also the market sorting it out.

Reply on news.ycombinator.com