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.
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.
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).
Oh don't get me started about this mess. I use Skype for the browser rather than any of the installable clients. There are days when it's simply not possible to login when you're redirected around that whole MS "live login" thing.
Every other time I've logged into to a MS site (say my dev account for VS Community) some other login for something else run by MS breaks...then I have to go hunting down cookies to delete. I've wasted tens of hours of my life over the past few years on this crap.
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.
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.
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.
Just to illustrate, the "horse battery staple correct"[1] - type passwords won't fit into 16 characters - and I can type that faster than QuyigGiX_07~! - type nonsense that most websites require.
Add to that the wonderful restrictions (oh, Citi doesn't like special characters that are too special, so QuyigGiX-07! it must be, etc), and you have a guarantee for frustration.
I guess it all comes down to the fact that people aren't going to stop using a service because the password UX is horrible - especially given that it's nearly uniformly horrible elsewhere.
Both passwords are just as practically secure against online attacks with the former being less secure against modern password cracking attacks.
A passphrase without any substitutions has words as atomics while languages have a very large number of words commonly used words offer a much more limited search space.
So say a 4 word passphrase of 4-8 letter words in the English language when limited to the top 5000 common words isn’t secure against offline attacks by any stretch of the imagination nor does it actually provide its level of entropy because you are no longer using individual characters as your atoms.
The latter password is essentially much more secure as it’s atoms are individual characters.
The former has an advantage which makes it easier to remember and faster to type.
Wait until I debut my password management service that converts a yoddle into an ascii string. That’ll certainly be more than 1000 chars. Our mutual customers will be disappointed when they can’t login to your sites.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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...
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.
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).
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.
>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?..."
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).
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.
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.
I can actually see a case for case-insensitive password provided that other security measures are in place, and that there is an entropy requirement somewhere. I doubt that is the actual reason why those banks have it implemented, but it could certainly be argued that people will remember their passwords better if case is not an issue; and lets face it, most remember-able passwords will either be all of one case, or have the first letter capitalised. Goes back to the saying "Security at the expense of usability comes at the expense of security".
This argument is based on the assumption of passwords needing to be remembered, which is certainly debatable from a security POV, but it a very common use pattern by humans.
You're assuming their database doesn't leak and that account lock becomes irrelevant. Some banks are probably even storing passwords in plain-text or very old hashing methods that are not very effective in 2018.
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.
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?
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.
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.
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)?
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.
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.
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.
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...
2FA would be great, so long as SMS isn't the only option every time. I've moved to a much more tech savvy bank these days, but there was a long while were my bank's website was, by a hilariously wide margin, the least secure website that I regularly visited. It was in fact one of my reasons for switching banks (the other reasons are not relevant here).
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.
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.
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.
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.
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".
