Hacker News Reader

Comment by aftbit | Hacker News Reader

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.

View on HN

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.

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

As did HSBC.

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.

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.

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, "ÈÍ§¾÷øÏ¡þää£àèÀ¸Àþ¡ï×ÕÞ£¸«"

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 )

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

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

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…!

Reply on news.ycombinator.com