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

81–90 of 327 posts

Re: Sites with dumb password rules

#81

Post by rurp »

jdelman wrote: post #47

My favorite dumb password experience involves EZPass, a system for paying tolls without cash, in New York. I signed up for EZPass using a relatively “long” password (20 chars). I then received a letter in the mail about a toll I had to pay, even though I’d had the EZPass at the the time. But, the letter said, I could pay the toll by logging in to their site and using my EZpass credentials. Didn’t use OAuth but I figu…

My local bank made a new website that does something similar, where the input for creating the password is truncated to be shorter than the field for entering the password. I forget the exact length but it is pretty short, like 10 characters. It took me forever to figure out why I couldn't log in to their new site.

Re: Sites with dumb password rules

#82

Post by rolltiide »

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.

Hi, this needs a checklist or ability to see severity of infractions because some of these edge cases are very dumb to elevate alongside the truly broken flows

Re: Sites with dumb password rules

#83

Post by yjftsjthsd-h »

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.

Why would you ever need that? If you have administrator access, just perform whatever the local equivalent of `su` is.

Re: Sites with dumb password rules

#85

Post by medmunds »

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

Re: Sites with dumb password rules

#86

Post by panarky »

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.

Using uppercase and lowercase letters and the symbols Chase supports, 0.25% of random 12-character passwords would be rejected by the repeating and consecutive rules.

Re-running the simulation to assume case-insensitivity results in 0.44% of random 12-character passwords failing these rules (assuming Chase treats aBc as an invalid sequence).

Note that Facebook also accepts variations on a password, for example if you have caps lock on, or if the mobile device automatically capitalizes the first character, or if an additional character is added at the end of the password.

More discussion on Facebook's policy here -> https://news.ycombinator.com/item?id=13426544

Re: Sites with dumb password rules

#87

Post by carterehsmith »

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.

Um... if "they" are system administrators, they do not need to brute-force password. They can just change it to whatever they want.

Re: Sites with dumb password rules

#88

Post by bscphil »

rolltiide wrote: post #82
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.

Hi, this needs a checklist or ability to see severity of infractions because some of these edge cases are very dumb to elevate alongside the truly broken flows

Yeah, compare the very first two on there right now. The first is "can't use '%'". The next one has 7 very specific rules.

Re: Sites with dumb password rules

#89

Post by FabHK »

jacobwilliamroy wrote: post #57
_hyn3 wrote: post #33

Earlier quoted context omitted.

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…

I have actually thought about this a lot and done some napkin calculations: using a set of about 93 characters the search space for 5 character passwords is about 7 gigabytes; combining all the possible passwords <= length 4 is only about 74 megabytes in comparison. I think that the entropy loss is insignificant.

Indeed, and the factor is about 95, which is close to 93, and that is not a coincidence, when you think about it.

If you want to crack my password, and I tell you that my password is L characters long, by skipping all passwords of length In other words, telling someone the length of your password does not help them very much.

Re: Sites with dumb password rules

#90

Post by viraptor »

vortico wrote: post #40
exabrial wrote: post #25

Want to DDOS somebody? Try their password incorrectly three times. Stupidest password rule ever. Rate limiting after 3 mis-attempts is understandable. That rate limit doesn't need to exceed 1m with passwords over 14 characters.

I don't even think rate limiting after 3 mis-attempts makes sense. I regularly can't remember my password and might need 6 attempts. Nobody's going to guess your password after 300 attempts, so make the limit 30 and you're safe.

While it doesn't really justify locking accounts, there's an approach to guessing passwords where you have a large list of accounts available and try each with top 10 passwords, then top 100. Given enough accounts, some will work. (Password spraying) so even limiting to 30 tries wouldn't stop it.

Ideally you'd detect one source trying logging into multiple accounts with many failures instead.

Post reply on HN