Hacker News Reader

Comment by doki_pen | Hacker News Reader

Bad example. Stupid password requirements are great because it makes it more difficult for users to use the same password on every site.

View on HN

No, it's a great example. I use a password manager that generates strong random passwords with special characters, but still run into problems on websites:

    * My password is too long
    * My password doesn't contain one of their required special characters
    * My password contains a special character they don't explicitly support

I loathe too long problems - if only because instead of letting me know they silently truncate the password to their maximum! But only on the password change form - the rest of their site accepts the long one for checking.

I now intentionally limit the longest password my password manager will generate to 12 characters now, just to avoid this mess.

Fair point. But for people who are doing these: please put the same instructions what is needed for the password when logging in the later time through normal login process. It might help to remember the password better (at least would help one person on this planet, me).

(edit: fixed typos, not a native english speaker here)

My solution is that I create a password, then promptly forget it. When I want to use that site again, I simply click the "forgot my password" link and create a new one.

Basically, if I don't use a site every day, or it isn't sensitive like banking information, I don't really even have a password.

I am willing to bet that a lot of people are "Login via email" just like me!

Stupid password requirements inevitably conflict with the random per-site passwords generated by Safari and iOS, LastPass, 1Password, etc.

And banks aren't immune to the stupidity:

https://blog.agilebits.com/2015/03/23/an-open-letter-to-bank...

Isn't this simply the thinking that is criticized in the article? Not every matter needs a regulation on it that might break another workflow in the meantime.

Yes, distant regulations rarely compose well for unpredictable local workflows. The closer a policy/rule can be to the edge, local to the affected users, the better chance of it being composed into a useful process that can adapt to new circumstances.

Passwords need regulation though. How many people are going to use a common dictionary word, password1, 1234, the name of their cat etc. if they can. Forcing them not to is good for you and good for them.

That way the users will have to constantly request a password reset.

Accept that your site isn't special enough to have a unique password and stop being so fucking arrogant.

Reply on news.ycombinator.com