Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sites with dumb password rules

github.com

Post reply on HN
Print view View original

91–100 of 327 posts

Re: Sites with dumb password rules

#91

Post by FabHK »

_hyn3 wrote: post #33
brokensegue wrote: post #16

Earlier quoted context omitted.

doesn't any rule decrease password entropy?

It's ironic that allowing low-entropy passwords (for example, one-character) can actually increase the available entropy. For example, if you set a minimum password length of six characters, an attacker doesn't even need to bother going through all of the 1 through 5 character combinations. The flip side of the coin is that, obviously, allowing low-entropy passwords will inevitably mean that some users will actually…

> can actually increase the available entropy

Well, the theoretical entropy, but not the empirical.

You could argue that ruling out "12345678" and "password" and "Password!" reduces the "available entropy" and makes things less secure (after all, your random password generator might just randomly have generated "12345678"), but in practice quite obviously it makes things more secure.

Re: Sites with dumb password rules

#92

Post by droopyEyelids »

medmunds wrote: post #85

For a nice counterexample, check out login.gov, the unified authentication service that seems to be replacing individual approaches at many US government sites. Their password requirements: “It must be at least 12 characters long and not be a commonly used password. That’s it!” [1] Oh, and login.gov allows pasting from a password manager. [1]: https://login.gov/help/creating-an-account/how-to-create-an-...

For more good .gov stuff, check out the dotgov Mac terminal theme https://github.com/lysyi3m/macos-terminal-themes/blob/master...

Re: Sites with dumb password rules

#93

Post by medmunds »

duffn wrote: post #54

Hi, I made this. It seems like most of you are as enraged as I am about some of these password rules. They just flat out make me mad. It's not much, but I've actually had one company reach out to me after making it on the list and they made their password rules less dumb. So, if you find any particularly egregious offenders, do your part and submit a PR. It may actually make a difference.

> I've actually had one company reach out to me after making it on the list and they made their password rules less dumb.

That’s a huge win!

My pet peeve is sites that block pasting, say, from a password manager (glaring at you, Costco signup page). Those sites don’t usually include “do not paste” in the listed requirements, so this doesn’t really work with your screenshot approach. Ideas?

Re: Sites with dumb password rules

#94

Post by FabHK »

zeta0134 wrote: post #20
OJFord wrote: post #11

Honestly, I'm past caring about upper length limits, however stupid they are. What really pisses me off is not validating on it, so my too-long password is happily accepted, and I have no idea what it is except that it's some prefix of the one I saved.

Reasonable upper limits don't bother me all that much. If you're going to store a hashed password, you want to choose an expensive hash algorithm (It's been a while since I looked at this, but I don't think bcrypt is standard anymore?) and that complexity is meant to be computationally ridiculous, and probably scales with length. Good security dictates a minimum length, and practical avoidance of your login form bein…

> that complexity is meant to be computationally ridiculous, and probably scales with length.

I'd think that there is an initial hashing (which is quite fast), and then iterated computations on that fixed length, with a more or less predictable (and high) CPU and memory intensity - in other words, not (significantly) scaling with length.

Re: Sites with dumb password rules

#95

Post by twunde »

flavor8 wrote: post #21

There are so many compliance reviewers who get stuck on our "high entropy" approach to passwords when doing security reviews for a sale. "But what about special characters? Mix of upper & lower? etc." I'm very grateful to NIST for https://pages.nist.gov/800-63-3/sp800-63b.html and Sophos for their summary here https://nakedsecurity.sophos.com/2016/08/18/nists-new-passwo... (both of which make fine references when req…

As much as I'm grateful for the improvements made to NIST and the slow trickledown to other compliance frameworks (HITRUST, etc) there are still major compliance frameworks that require password changes and mix of upper/lower/special characters including PCI (see https://pciguru.wordpress.com/2019/03/11/the-new-nist-passwo... for a more detailed discussion). It's frustrating that while 80% of the time compliance frameworks reinforce security, 20% of the time compliance frameworks actively prevent better security.

Re: Sites with dumb password rules

#96

Post by twistedpair »

bonestamp2 wrote: post #70
panarky wrote: post #14

Chase Bank: Must not include more than 2 identical characters (for example: 111 or aaa) Must not include more than 2 consecutive characters (for example: 123 or abc) First, they apparently mean repeating and not identical characters. But more importantly, perfectly random character strings frequently contain repeating and consecutive characters, so this rule must reduce the entropy of passwords. ------ Edit - Just si…

When you did your simulation did you use lowercase and uppercase letters? I ask because chase.com doesn't differentiate between the two. Seriously. If you have a chase account, try changing the case of some of your letters and you'll still login successfully.

This is often so you can enter your password in a touch tone phone, since there are no caps there.

Re: Sites with dumb password rules

#97

Post by ineedasername »

I thought it was fairly well established in the tech community that something like a sentence you can easily remember is better than a weird sequence of 12-20 letters, special chars, etc. But I very, very rarely see any site ever mention or require it or anything. How come it hasn't taken hold?

Re: Sites with dumb password rules

#98

Post by doubleunplussed »

flavor8 wrote: post #21

There are so many compliance reviewers who get stuck on our "high entropy" approach to passwords when doing security reviews for a sale. "But what about special characters? Mix of upper & lower? etc." I'm very grateful to NIST for https://pages.nist.gov/800-63-3/sp800-63b.html and Sophos for their summary here https://nakedsecurity.sophos.com/2016/08/18/nists-new-passwo... (both of which make fine references when req…

Ironically, if you ever get an IT account on a NIST campus, they dont follow their own rules. It's "at least one capital letter, one digit and one symbol, and can't contain any English words of 3 letters or more" or similar. And they make you change it every 6 months. Pain in the neck.

Re: Sites with dumb password rules

#99

Post by bscphil »

BluSyn wrote: post #75

I'm a proponent of only 1 simple rule: high min length. Most sites have min length of 8. Double that to 16-20. No max length, no other complicated restrictions regarding characters. This instantly takes care of brute-forcing as a reasonable possibility, and forces good pass phrase discipline on the user.

> forces good passphrase discipline on the user.

I definitely don't think it does this. In fact it probably makes most people much more likely to use the same password on every site, since their passwords just became 3-4x harder to remember.

Re: Sites with dumb password rules

#100

Post by ineedasername »

aaronchall wrote: post #61
txcwpalpha wrote: post #37

Earlier quoted context omitted.

Sounds like they were using z/OS or RACF [1] mainframe as a backend. Oof. Unfortunately, it's not that uncommon. I've done security consulting work at a few major F500 companies that were using this and had those same password rules. At one of them, it got to the point where almost every security review meeting had to start with "yes yes we already know how bad the password are, don't bring it up, let's talk about so…

I suspect they want to be able to brute-force passwords if they really need to, in the event of a uncooperative or malicious employee, and these rules allow for that.

Nah, they tend to be systems whose original infrastructure was written pre-internet and had 3 or 4 (or more) decades of bolt-ons laid on top. Password security wasn't nearly as much of an issue, but now the same system that had been designed for employee use now is used by customers and is exposed to the web. Kind of like taking a lock on a diary meant to prevent casual perusal by a sibling and puting it on a bank vault because you put the diary in the vault.
Post reply on HN