5 ms·

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

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 simulated this for 10 million 12-character passwords randomly generated from the 90 characters Chase allows. Turns out the repeating and consecutive rules would invalidate about 0.3% of purely random passwords. A negligible reduction in entropy is certainly more than offset by preventing passwords like aBc123456789.

brokensegue 7y ago
doesn't any rule decrease password entropy?
- graphememes 7y ago
  Yes, but no, but yes. What I believe the original poster was hinting at and I believe you, witty little you, also understood was the rule severely inhibits the entropic nature that you would rather see. Something like minimum characters pushes towards a more ideal entropic state for example, rather than limiting the ideal entropic state.
- twiceaday 7y ago
  The maximum possible entropy is in a sense sampled by users various passwords. The sampling can be biased, so rules can technically eliminate such biases and lead to higher effective entropy. Furthermore, there is a benefit in forcing the user to not share the same password across multiple websites which can be achieved by imposing extra (or ideally mutually exclusive) password rules. Of course I am just playing devils advocate here.
  - jdashg 7y ago
    What's hell is not being told /at login/ what the unusual restrictions are.
- _hyn3 7y ago
  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 use them, which means that their passwords actually have decreased entropy.
  - jacobwilliamroy 7y ago
    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.
    - FabHK 7y ago
      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 < L you've only saved about 1/N of the required effort (where N is the size of the character set you choose from). In other words, telling someone the length of your password does not help them very much.
      - _hyn3 7y ago
        The impact of this really depends on the cost of calculating hashes, which varies based on hash algorithm. It might even be the difference between being able to ever find the hash or not. Being able to constrain the search space is the ONLY tool you can count on. If you say "No passwords less than eight characters", most passwords will be clustered around 9 or 10 characters. That's human nature. This means that your entire search space is only the character set in that very limited set of strings. And, if you're limiting that character set, and also it's expensive for you to hash (ie scrypt or bcrypt with lots of rounds), then not having to go through the first 1-8 set will save you a tremendous amount of time...
savanaly 7y ago
Does it reduce the entropy of passwords in practice or just in theory? It could be that in practice if you let users repeat characters they will do so more often than random chance would allow for, thus making their passwords predictable to some degree. Thus, prohibiting that practice would increase the randomness of passwords actually getting used.
- jdashg 7y ago
  My 16-char alphanum generated password for Chase had an equivalent of "rST" in it. I can never remember which password modification I ended up with, and "can't choose the same password as your previous 4" gets real old real fast.
bonestamp2 7y ago
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.
- panarky 7y ago
  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 https://news.ycombinator.com/item?id=13426544
- twistedpair 7y ago
  This is often so you can enter your password in a touch tone phone, since there are no caps there.
pg_is_a_butt 7y ago
a246810Z
ivanhoe 7y ago
It's a naive approach, and also honestly, in my personal experience with banking software, these rules are not selected through some careful secops research, but are usually arbitrary picked to sound smart to managers and be easy enough to implement by devs. Bad passwords should be addressed specifically, because having "ijk" or "777" somewhere in you 40chars long random sequence is not really a vulnerability. On the other there are many bad passwords that are not made of sequential numbers, say "qwerty" or "asdfghjkl" or "sunshine". There're so many data dumps these days that it's easy to create a blacklist of popular passwords and block it, without giving headaches to users with password managers just because their safe random password happens to have a wrong number of these or those chars.

brokensegue 7y ago

doesn't any rule decrease password entropy?

graphememes 7y ago
Yes, but no, but yes. What I believe the original poster was hinting at and I believe you, witty little you, also understood was the rule severely inhibits the entropic nature that you would rather see. Something like minimum characters pushes towards a more ideal entropic state for example, rather than limiting the ideal entropic state.
twiceaday 7y ago
The maximum possible entropy is in a sense sampled by users various passwords. The sampling can be biased, so rules can technically eliminate such biases and lead to higher effective entropy. Furthermore, there is a benefit in forcing the user to not share the same password across multiple websites which can be achieved by imposing extra (or ideally mutually exclusive) password rules. Of course I am just playing devils advocate here.
- jdashg 7y ago
  What's hell is not being told /at login/ what the unusual restrictions are.
_hyn3 7y ago
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 use them, which means that their passwords actually have decreased entropy.
- jacobwilliamroy 7y ago
  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.
  - FabHK 7y ago
    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 < L you've only saved about 1/N of the required effort (where N is the size of the character set you choose from). In other words, telling someone the length of your password does not help them very much.
    - _hyn3 7y ago
      The impact of this really depends on the cost of calculating hashes, which varies based on hash algorithm. It might even be the difference between being able to ever find the hash or not. Being able to constrain the search space is the ONLY tool you can count on. If you say "No passwords less than eight characters", most passwords will be clustered around 9 or 10 characters. That's human nature. This means that your entire search space is only the character set in that very limited set of strings. And, if you're limiting that character set, and also it's expensive for you to hash (ie scrypt or bcrypt with lots of rounds), then not having to go through the first 1-8 set will save you a tremendous amount of time...

savanaly 7y ago

Does it reduce the entropy of passwords in practice or just in theory? It could be that in practice if you let users repeat characters they will do so more often than random chance would allow for, thus making their passwords predictable to some degree. Thus, prohibiting that practice would increase the randomness of passwords actually getting used.

jdashg 7y ago
My 16-char alphanum generated password for Chase had an equivalent of "rST" in it. I can never remember which password modification I ended up with, and "can't choose the same password as your previous 4" gets real old real fast.

bonestamp2 7y ago

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.

panarky 7y ago
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 https://news.ycombinator.com/item?id=13426544
twistedpair 7y ago
This is often so you can enter your password in a touch tone phone, since there are no caps there.

pg_is_a_butt 7y ago

a246810Z

ivanhoe 7y ago

It's a naive approach, and also honestly, in my personal experience with banking software, these rules are not selected through some careful secops research, but are usually arbitrary picked to sound smart to managers and be easy enough to implement by devs. Bad passwords should be addressed specifically, because having "ijk" or "777" somewhere in you 40chars long random sequence is not really a vulnerability. On the other there are many bad passwords that are not made of sequential numbers, say "qwerty" or "asdfghjkl" or "sunshine". There're so many data dumps these days that it's easy to create a blacklist of popular passwords and block it, without giving headaches to users with password managers just because their safe random password happens to have a wrong number of these or those chars.