Hacker News Reader

Comment by Terretta | Hacker News Reader

> The usual advice about character classes is only for casual users who don't know what makes a secure password.

Arguably, it was to make early rainbow tables less feasible.

> if you are already generating the password, please do not include special characters.

This would make your generator useless on most sites. Since it's not the generator making up this rule, it's the web site's password "complexity" requirements.

I do agree password strength tests should just measure bits of entropy and allow whatever's typed that's high enough.

View on HN

I like to subvert those sites by just adding A1! to the end of every otherwise totally lower-case password.

There is a special place in hell for anyone who creates a maximum password length limit, however. That prevents passphrases and gains nothing. If you're working with some weird legacy system that can't handle long password (worst way: just truncating them and matching the first 8 characters), then add Argon2 or heck even SHA where you otherwise add the password length check.

even worse when they don't properly enforce it and instead silently truncate it.

There was a PayPal bug just a couple years ago where the reset-password page didn't enforce length like other pages did. So it allowed you to create an otherwise illegal password and then your account is completely locked out (I guess, unless you realized the truncation was happening...)

And so I would reset my password, generate a new one... and it would happen again. Took me a while to realize it was the length and not a special character I added messing up with bad encoding logic or something.

> even worse when they don't properly enforce it and instead silently truncate it

JetBlue truncated to 10, e.g.:

    fly0nJetBlue -> fly0nJetBl

So I can tell you it's even worse when they silently truncate it on save, and on some logins, but not on all logins!

I went through this hell just last week with their terrible website. Jetblue has fallen a gew notches over the years.

Thank you for confirming I'm not crazy. I remember having the same problem a few years back and looking up online if anyone had the same problem as me, but found nothing at the time.

When I am forced to rotate an otherwise good password, I swap the suffix to the front of the password

If they have some perverse check to make sure I am not re-using one of my last X passwords I just rotate in another permutation like A2!

This is the exact reason why NIST, for the better part of a decade now, has strictly recommended against arbitrary password rotations. All it accomplishes is frustration for users with no tangible increase in security (because everyone just increments their password, or follows other simple patterns).

Some research suggests that arbitrary password rotations results in a real-world decrease in security, because as users get frustrated they make simpler and simpler passwords.

I worked in IT at a tech company that had mandatory 90-day password rotations. That place had the highest rate of “password on sticky note” that I’ve ever seen.

On the tenth call to my bank in the same year to reset one of our user passwords, the account rep just volunteered to them the information that "there is an option you can check on an obscure settings page to NOT have the mandatory password rotation, you know".

At a bank back in the Blackberry days they were handed out with Qwerty1 as the default password. Just incrementing the digit would get you into 80%+ devices in the firm.

I worked for a financial company that had 29 day password rotation. One day I accidentally logged in as my colleague. Our user names differed by just one letter so I simply mistyped. It turned out we used the same password scheme to keep up with the rotation and stupid special character requirements.

My memory is that PCI regulations require password rotation every 90 days - also that the minimum password length should be seven characters, not the eight I always answer when quizzed.

PCI DSS 4.0[0] requirement 8.3.9 updates this to 12 characters and only requires rotation if the password is the only factor used for authentication.

[0] https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard...

If I remember correctly they only recommend against password rotation when MFA is in place, which is significantly more important anyway.

Unless there's a rate limit for changing passwords I just rapidly change them X+1 times and arrive back at my original. This only applies to work stuff, which I don't keep in my password manager.

In my experience, changing the password at big corps usually locks you out and requires a call to IT. I had a success rate of about 50% when I had to change passwords. It was the most frustrating thing...

"Oh yeah your password change properly is not synced to all servers yet. Just wait and try again later"

"Oh you tried the new password too many times while it was not synced yet. Your account is now locked. You need a manager approval to unlock your account."

Symbols should be restricted to the set that are mostly insensitive to keyboard layout.

'!' is a good one. Quotation marks are not. Currency signs are not.

I usually just throw a period in there.

I remember being shocked when I realized that Charles Schwab, a bank that manages untold illions of dollars, was ignoring everything after the 8th character in their passwords. This was still true until a few years ago.

I remember this. I had enough funds with them at the time (and I am also in tech so I insisted on a technical explanation) that I was able to speak with their security team about the reason for the limit and when it would be fixed. It has been fixed and they require 2FA now (however they require a very specific app for it). Overall my experience with them over the last 10 years has been good.

TLDR; limit on older mainframe system, however password were properly hashed & they plan to remove the limit in the next year, which they did.

A bunch of the Canadian banks too. TD Canada Trust I can personally confirm.

This is a sign they're storing it unhashed on a mainframe system. Airlines also do it.

That’s not true. You can hash the truncated version

The desire to truncate comes from wanting to store smaller fields in the database.

Transunion (credit reporting agency) does this, but after the 15th character.

Wait til you see what Fidelity does.. https://www.fidelity.com/customer-service/faqs-managing-your...

> Usernames and passwords containing letters need to be translated to numbers to enter them in a Fidelity phone system (like FAST®, or if you call a representative). Use your telephone keypad to convert the letters to numbers. There is no case sensitivity. Substitute an asterisk (*) for all special characters. Here's an example:

> To enter a username, e.g., Smith123, press or say 7-6-4-8-4-1-2-3

> To enter a password, e.g., Lucky1$23, press or say 5-8-2-5-9-1-*-2-3

Lucky my password is very secure, "ÈÍ§¾÷øÏ¡þää£àèÀ¸Àþ¡ï×ÕÞ£¸«"

As did HSBC.

Agreed just because a company thinks my threat model doesn't require anything but letters and should be short enough to memorize, sure does not mean they are correct. Apple is collectively dumbing down complexity for selfish reasons and then not allowing you the user to change default complexity and length. Looks like the only problem they were trying to solve was reuse which might be a plus one for the Apple device population but I am not sure the trade off is really worth it. But hey it's free!

I use a password manager but usually leave it set to lowercase, uppercase and numbers.

Then you get my personal favorite, which is sites that force you to use symbols, but when you do, they say you've used illegal symbols, but don't even tell you what symbols they accept, or which of the ones you've used were illegal.

also, excessive minimums. I once encountered a website with 20 minimum characters, which I think is longer than some sites' max length.

I think 15 is a good secure minimum.

> There is a special place in hell for anyone who creates a maximum password length limit

People abuse everything, you can be dossed trying to compute <pick your hashing algorithm-of-choice> of a password as big as the maximum body size your webserver accept (which is a limit btw, so remember to dress light :-p )

Don't tell me that if you allow long passwords you'll run into the body size limit of the http server when you set the maximum password length to a measly 16 bytes because your choice of password hash scales like O(length(password)*iterations) which opens you up to a denial of service if you allow longer passwords. 50, 100, even 200 byte passphrases are reasonable and make no discernible performance difference to sanely designed auth servers.

There's no reason* why the time a hashing algorithm takes to do security rounds should vary with the length of the user's password. If you want to prevent DoS as GP mentioned then run all passwords through one round of a (fast) secure hash algorithm, then do security rounds with the output. This is what Argon2 does by default https://en.wikipedia.org/wiki/Argon2

bcrypt has a built-in 72 byte limit, which helps with the DOS issue

70% of all passwords in Japan. 8-10 characters max length is the most common.

I understand where it comes from (having computer systems designed by people who never spend a second thinking about your language) but still.

It’s 2024!

Haha - i have the same kind of Logic. Would be great if Bitwarden would add this appendix as an option as it is required on quite a number of websites…!

Such sites that do not allow Apple passwords I now skip as a user (unless it’s a government site), it says enough about how you view security and there are plenty of competitors that don’t do this

What websites are those, I am curious?

Not GP, but I had one just the other day that didn’t allow dashes in the password, but did require a special character (of a list of like a dozen, just not including dash). Also, it wasn’t that the dash wasn’t recognized as a special character, but that it wasn’t allowed at all. Wish I could remember what site now.

It's not really meaningful to measure entropy of a single password, only of a distribution of passwords. You could assume a password comes from some distribution, but how would you know? Does "grefn" come from a distribution of "pick a 5 letter dictionary word and then randomly change one letter or a distribution of "pick 4-7 random ASCII characters"?

> It's not really meaningful to measure entropy of a single password

Here’s a ‘not meaningful’ formula then: E = L × log₂(R)

• E is the entropy, in bits, representing how hard the password is to crack.

• L is the password length (number of characters).

• R is the size of the character set (e.g., 26 for lowercase letters, 52 for upper/lowercase, 62 if digits are included).

• log₂(R) is the number of bits needed to represent each character.

I hear your point: a single password might not actually use all character types, so the actual entropy could be less than its potential. Maybe they could have drawn from a wider range and didn’t.

But for everyday user feedback, assuming the fewest sets seems fine to nudge people toward picking stronger passwords.

One definition for the randomness of a finite string is the size of the smallest program that produces it. The definition is dependent on how programs are interpreted.

If my string is "aaaa", does that mean its entropy is zero? There is at least information about its length. And by your definition, how do we know that this password isn't from a 256 character set? Does "Aaab" have 26 times the entropy of "aaab"?

Topics like this make more sense to me when the strings are infinite, or when the population of strings is known.

A good password generator should check that the random generation did not give too many repeats or that the password is not easily guessed by a simple common password list

I don’t believe it’s possible to estimate the amount of entropy in a password - it’s too short so then you have to evaluate it against a dictionary. That’s why things are moving to passkeys but NIST recommendations thankfully have finally been updated to stop recommending weird password rules.

An important distinction that often gets lost is that entropy is a property of a probability distribution. A system to generate passwords has entropy, one specific password does not.

It's possible to read "hunter2" from /dev/random.

To infer entropy from a single password, the best you can do is to see if it falls within the domain of some known, low-entropy systems. This works ok in practice, but is very far from perfect.

To be fair, one specific password does tell you something about the entropy of the generator. If I can grab 1 MiB of data from your password generator, I can probably estimate quite well the entropy of the generator. 10-20 bytes? That tells you almost nothing (but still not nothing). That means there must be some way of updating an estimate of the entropy of the generator from every additional byte of output and the amount of confidence that you gain about that estimate grows (probably exponentially) with every new byte.

But your password is 10-20 bytes so you can say nothing about the generator.

Well, trying to infer entropy of a password by classifying it into the lowest possible low entropy system actually works well against brute forcing because brute forcing usually works exactly doing that.

That's the crucial point. You can have a super high entropy probability distribution straight from a quantum lava lamp, but if it gives you "hunter2" as a password, you should still not use that password, no matter the entropy of the distribution.

Right, I was just about to ask: Entropy is the measure of how "surprised" I'll get from the next character in the password. It's not a property of the password, it's a property of me. "Γεια" is very surprising to everyone here, as everyone would assume the first character to be English, but not if you know that the user is Greek.

>NIST recommendations thankfully have finally been updated

Finally? It's almost been a decade since since special publication 800-63B was published recommending against silly things like composition rules and arbitrary password rotations.

The NIST guidelines have changed "should not" to "shall not" for 800-63B this year. The reason this is important is that the very first NIST guidelines recommended rotations and composition rules. Even after 800-63B was first published, people continued to use the earlier guidelines under the assumption it was better and the "should" wording let them keep doing it. The shall change should force a broader change which is why it's significant. Another notable change this year is the banning of security questions:

> Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords and > Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator. > Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.

> Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.

Estimating entropy is challenging because it's a reverse process from how it ought to work. I created https://phrase.shop, which generates passphrases with a known quantity of entropy. Hover over any of the three action buttons to see exactly how many bits of entropy will be used to generate the passphrase.

In my personal website template I required a length of 15 characters and at least one of each: lower+upper case letter, number and symbol, to counter rainbow tables.

Doesn’t adding a random salt counter rainbow tables? Then you could have fewer requirements on the users

Yeah, it does. But I am over killing it cause I'm making stuff for myself and I'm using password manager.

Reply on news.ycombinator.com