Ask HN: Why is PayPal's password length limit still a thing?

https://news.ycombinator.com/item?id=16620016

by _drew_ • 8 years ago

112 82 8 years ago

news.ycombinator.com

With over 227 million active paypal accounts why is there seemingly no pressure on them to stop enforcing a password length limit?

giarc2• 8 years ago

Same goes for my Bank of Montreal in Canada. I have a credit card through them, and when I signed up (5-6 years ago) password criteria was 6 characters, no more, no less.

deft• 8 years ago

AFAIK it's also only numbers...

giarc2• 8 years ago

Not for the credit card at least.

hodl• 8 years ago

Prime numbers, in ascending order only.

jdlyga• 8 years ago

That card must have good rewards if you're sticking with a site like that.

imglorp• 8 years ago

If they get cracked, it's not the cardholder's problem. They have all of the risk.

skipants• 8 years ago

And their solution is: if you get the password wrong 3 times in a row you have to call them to unlock your account. I learned this the hard way, unfortunately.

ttsda2• 8 years ago

My bank has a fixed 8 digit number as the password, and mandatory SMS 2FA (which is flawed).

They also offer hw token login but you need to buy them and I don't think a relevant percentage of users uses those.

stordoff3• 8 years ago

Reminds me of my bank as well, which also makes using a password manager awkward and raises questions able how they are storing the passwords: "Enter character numbers m, n, o from your password".

MichaelGG2• 8 years ago

I've no insight to PayPal. But MS Live aka Passport aka Microsoft Account has a 16 char, limited character set limitation. I spoke with people that worked on the system. Basically, sometime a long time ago, someone made some code that checked this. And over the years, many other parts of the pipeline ended up coding it and depending upon the same restriction. They're aware of it, but it's not a worthwhile time investment versus other work. People don't get hacked because of the limit, they get hacked via phishing, reuse, etc. Spending time testing, debugging, fixing old code across disparate systems with possibly different owners is a big cost. There's higher priority work to be done, even within security.

tlb• 8 years ago

One would hope that plaintext passwords aren't fed through a long pipeline of legacy systems. As soon as it's hashed, which is the first thing you should do, length is no longer an issue.

davidli• 8 years ago

Yes, but you might have other legacy systems that implemented the validation rules for passwords. Changing these rules would prevent people from logging into legacy systems if they signed up via a newer flow with fewer restrictions.

Someone12342• 8 years ago

Microsoft have over five different places you can change a password (all of which conform to the same set of business rules). That's the issue, it isn't a pipeline issue, it is that Microsoft consolidated tons of different services under a Microsoft Account so have a ton of redundant ways of doing something.

Microsoft Accounts/.Net Account/Passports, are a huge mess in general that Microsoft need to fix. Password length restrictions still may not go away even if they did (for backwards compatibility reasons with older software/hardware still around).

reacweb• 8 years ago

That is the problem with limitations: they are hard to remove. I have the case where the character _ was invalid in project names. I have fixed the code to accept _ where it was invalid in first place. The problem is that other tools are now checking that project names do not contain _. How many tools in how many places? I do not know. The issue is not big enough to justify coordination of all the development teams to ensure that their code accept _ in project names. This limitation will probably never disappear.

tinalumfoil• 8 years ago

As hard as limitations are to remove, adding limitations later on is even harder. As a commenter above pointed out, bcrypt doesn't handle passwords longer than a certain length. Imagine you were moving from a hash without limit to one with a 16-chatacter limit. You would quickly wish you weren't so lenient on what passwords you accepted. The point is forcing reasonable limitations on people isn't always a bad thing.

stordoff3• 8 years ago

Live is definitely a bit of a mess. I changed my password a while back and, IIRC, included a '%'. Worked fine on PC/Xbox, but then I went back to a GFWL game some time later and found that it would claim my password was incorrect. Took me a while to work out -- I assumed it was just a bugged install because I could log in fine elsewhere, and a password reset didn't help -- but eventually realised that changing my password to something that didn't include that character let me log in.

eyeball• 8 years ago

I also enjoy sites that prevent pasting into password fields. Makes using a password manager a pita.

kileywm• 8 years ago

I feel the same way. A bandaid for the situation: you can use browser extensions/add-ons to restore paste functionality on these web pages. For example, I use this one:

https://github.com/aaronraimist/DontFuckWithPaste

ExactoKnight• 8 years ago

I had an idea for Firefox, which is to restrict copy/paste overriding completely from the DOM.

This would put a stop to Google's BS of overriding normal links top google-analytics-full redirect urls.

matt_wulfeck2• 8 years ago

I can’t believe this is a thing. It makes me rage every time. I have to go into dev tools and just insert the value myself.

raverbashing• 8 years ago

It's like a physician recommending the USDA food pyramid (the one filled with HFCS)

shmerl• 8 years ago

Some password managers (like keepassxc) can emulate keyboard input.

exalsy• 8 years ago

The GNOME DE does this as well. Whenever I have a fresh Linux install and I try to enter the passwords in the "Online Accounts" section I'm reminded of it... so frustrating.

na85• 8 years ago

Yet another reason not to use Gnome. They seem to have decided to make the DE as unusable and obtuse as possible.

oasisbob2• 8 years ago

Is this restriction more common in certain countries?

In the US, I've fortunately never seen paste blocked on a login page. Wondering why.

adrr• 8 years ago

Its common in the US, i see it every couple weeks. It effected me last night on the Costco Travel site when creating an account. It let me paste the password but not the confirm password field.

colejohnson66• 8 years ago

I’ve seen it when entering in my bank’s routing and account number. Like, seriously? I’m less likely to type a digit incorrectly if I copy and paste...

peeters• 8 years ago

Also their cousin; those that allow programmatic entry/pasting, but then detect whether the user has provided a value based on keystroke listeners rather than current field value. So you still need to hit space+backspace in the field to let the client JS know you've entered something.

larkeith• 8 years ago

Generally speaking, that's one of the best ways to get me to not use your site - It's both inconvenient and shows your security team to be incompetent.

Bokagha• 8 years ago

On macOS I use https://github.com/EugeneDae/Force-Paste to get around this. It uses virtual keyboard to type in the text from your clipboard. Also helpful for using the password in programs that don't allow paste.

sowbug• 8 years ago

The scary cousin of this antipattern: the login form that browsers' built-in password managers can't see. Building the DOM using pathologically dynamic methods, using nonstandard input fields, giving the username/password fields ridiculous names, etc.

This tells me that the developers don't use password managers themselves, which means they probably use hunter2 for all their passwords, which means they don't know or care about conscientious security practices... not the folks I want to have built the site I'm about to use.

jim_d• 8 years ago

Agreed, I always double check that the browser password manager works, but it's tricky because there is no standard around what the fields should be called to make it always work. The best way to make sure it works is to put the username directly above the password in the same form, that will result in most password managers working, and this is especially important on registration forms.

Also for those that don't know why hunter2 was used above, enjoy! http://i0.kym-cdn.com/photos/images/original/001/065/965/989...

rasz• 8 years ago

document.getElementById("password").value = "myvoiceismypassword";

var event = new Event('change');

document.getElementById("password").dispatchEvent(event);

done

askvictor2• 8 years ago

My general solution here is, if I can possibly avoid it, to not use that site/service.

paulpauper• 8 years ago

Paypal is so strict that even if one knew the password and email they could still could not spend. Paypal forces phone verification if they don't like the IP, which is very common. The phone must match the ID of the paypal account holder, so using a throwaway number will not work.

matt_wulfeck2• 8 years ago

So again if they take it so seriously why enforce such an arbitrary limit on password length?

tracker12• 8 years ago

Probably weird arbitrary rules around legacy systems... I don't know about PayPal specifically, they're really too young that it shouldn't be an issue. I know other banks with account federation have had some systems running that are severely limited. It's weird all the way around tbh.

I do hope the new NIST recommendations get more weight moving forward, but banking tends to rely on other authentication/validation routes beyond just the password to strengthen things. Which is probably okay.. unless your device is found, and not password protected itself, with a relatively secure password. Even then...

stordoff3• 8 years ago

How strict? I've accidentally used my PayPal account whilst connected to a (out of country) VPN more than one and never had it raise any flags, and I've _never_ had phone verification for a purchase.

tracker12• 8 years ago

Two of three bank sites I log into regularly are limited to 8 alphanumeric characters, I'm frankly unsure if they even distinguish letter case.

It's probably time to start holding these sites accountable, however anything that could be proposed as regulation by the gov't on this would be a clusterfuck in implementation details, so I have bad feelings all around. I agree that there should be "unlimited" or reasonably limited (64-256 character limit) in input, since hashing will take care of the rest. Personally, I'd love to be able to use pass-phrases, ie, "Because, cookies are awesome!" ... Most of my "really" secure passphrases are like that (password manager, authy, etc).

vorpalhex• 8 years ago

Some DBMS' do require a limit... eventually. I think 256 is a reasonable bound, since that allows very generous pass phrases.

And actually, the NIST password recommendations are very reasonable, at least currently.

nokcha• 8 years ago

But you shouldn't be storing a raw, unhashed password in the database anyway.

Someone12342• 8 years ago

The current NIST requirements almost read like someone at NIST read the famous XKCD[0] and decided to implement it. Likely the best standard we've ever had in its reasonableness.

[0] https://xkcd.com/936/

maxk42• 8 years ago

You failed the test. Back to Security 101 with you!

The point being made is that all passwords should be hashed and a hash is going to be fixed-length. Therefore there should be no limit on password length beyond, say the limit of the total HTTP POST size -- but you're not using a megabyte-long password, are you?

layoric• 8 years ago

Only the hash should be stored so limit of the original password is mute

oasisbob2• 8 years ago

Are your banking sites smaller? (Eg, credit union)

One core financial stack I know of stores home banking passwords unencrypted. They transcode ASCII -> EBCDIC to obscure the password and call it a day.

navidfarhadi• 8 years ago

I can confirm this. Wells Fargo, a very popular bank in the US, limits passwords to 6 to 14 characters. In fact, your passwords are not even case sensitive. This is absolutely unacceptable in 2018.

I no longer have any bank accounts with Wells Fargo. In fact I don't have any bank accounts with any of these banks that have these stupid password restrictions.

mackey• 8 years ago

I almost didn't believe you because their own password page says to use mix case, but I just tried it... and flipping case totally works. Crazy!

soneil• 8 years ago

re: case insensitive .. I've heard of a bank with a similar problem, I don't recall which, where the reason was legacy compatibility with touch-tone phones. The password was normalized to something you could key in on a phone.

This isn't an excuse, just a poorly-remembered anecdote as to how backwards some of these systems are.

antoncohen• 8 years ago

Sadly, if the limit is 8 characters, they might be using something like the original DES provided by crypt()[1], it silently truncated to 8 characters. Or they may have moved on to something newer by now on the backend, but have the 8 character limit hardcoded in a bunch of places.

[1] https://en.wikipedia.org/wiki/Crypt_(C)#Traditional_DES-base...

developer2• 8 years ago

Tangerine (Canadian bank) only offers a choice between exactly a 4-digit or 6-digit password. These are numeric digits, not alpha-numeric. Yes, this is for online and telephone banking, not just one's debit card PIN - though I'm sure most people use the same 4-digit code for both.

These may as well be stored as plaintext. What would be the point of hashing when you're dealing with a mere 10,000 permutations for 4-digit passwords (or 1,000,000 for 6-digit)?

lazyjones• 8 years ago

I wouldn't be surprised if they shared plaintext passwords with other entities. They are very useful for identification across multiple accounts.

throwawayReply• 8 years ago

Note that bcrypt has a maximum length well below some of the lengths mentioned in this thread:

https://security.stackexchange.com/questions/39849/does-bcry...

Given this, it seems reasonable to restrict input below a length where the password will become (effectively) truncated by blowfish.

That length is also well above 10 characters however.

lightbyte• 8 years ago

A common method I've seen to get around that is to first hash the password with something like SHA512 before applying bcrypt. This allows you to use longer passwords as well as setting them all to a constant length for bcrypt (which can potentially remove a ddos vector).

ttsda2• 8 years ago

One could argue that above 56 bytes the truncation wouldn't matter for security anymore, since you already have quite a bit of entropy to spare in my opinion.

romwell2• 8 years ago

From the linked SE thread:

One way to work around it is by using SHA-256 first and then BCrypt the result. In your case it would be something like
hashpw(sha256('pass'), salt)

And if that doesn't roll with you, ignoring the extra characters and giving a warning when the password is set is still a way better UX than forcing your users to remember the arbitrary password length limitation you picked.

"My password for this site should be 'horse battery staple correct', but it doesn't fit. I can type only 'horse battery sta'. Let's see, oh, it doesn't work. Guess I've truncated on word boundary. But did I include the trailing space?..."

skookumchuck2• 8 years ago

I learned long ago in programming that setting arbitrary limits seems simpler to code, but in the end it is more work. You need to deal with error messages, error recovery, user instructions, and complaints from users. It's so much simpler to just allocate memory for whatever size the data happens to be.

Then, you just have to deal with one generic "out of memory" situation.

MichaelGG2• 8 years ago

So on a modern machine that might mean a user can submit a 1GB password?

Klathmon• 8 years ago

Your server should still have POST size limitations and other limits to prevent DoS.

cmccart• 8 years ago

For inputs that are going to get hashed that seems reasonable, as well as for single-purpose systems. On the flipside, this seems like a great way to have unintended consequences downstream in more complex systems. That "out of memory" condition may appear as an ephemeral bug or slowdown that surfaces not at input time but at retrieval by another service.

oliwarner• 8 years ago

When people make excuses like "engineering time to overhaul the database" I'm slightly aghast.

They should only need to store a hashed password (of whatever length they like). The actual length of my password shouldn't matter because it shouldn't be stored. Expanding the forms to go from 16 characters to 160 characters should not incur a storage problem.

If that is an issue, they have bigger problems than only allowing 16 characters.

illvm• 8 years ago

Battle.net passwords are also not case sensitive and have a strange complexity requirement for similar reasons. Too many code bases implemented it this way and it's hard to fix it without breaking compatibility with older software.

Ask HN: Why is PayPal's password length limit still a thing?

Related Stories