Hacker News Reader

Comment by brobdingnagians | Hacker News Reader

> “We reported this in February 2019 to PayPal via HackerOne,” they say. “After an initial rejection and several discussions, PayPal paid a bug bounty of $4,400.” The pair have not heard from PayPal, they say, since April 2019. But this week “tried and could still use the virtual credit card for online payments.” That means, they told me, “the bug has not been fixed.”

> But in terms of the Fenske and Mayer disclosure, the researchers told me that this is not fixed, even after PayPal’s “mitigation” statement.

If Paypal has known about it for a year and it still isn't fixed, then it means that either 1. Paypal didn't understand the bug report and "fixed" something else 2. Paypal understood the bug report, didn't fix it, and is trying to save face. Either one of those sounds pretty bad for their security policy...

View on HN

As for paypal's security policy, note that they have a maximum password length of 24 characters, and routinely send people e-mails with a big 'log-in' link.

These are both bad practice. The password length limit reduces the quality of passwords, and suggests plain-text storage of passwords. The sending of log-in links makes people much easier to phish, since people are used to clicking on a link in e-mail and then entering their credentials on the site.

Recently, I received an E-Mail which looked a lot like a phishing attempt. It contained a link to sign in to "paypal.com", but when hovering over the link, it was revealed to be something like "https://epl.paypal-communication.com/T/ve3648d90e0f976ec10e4.... Really stupid idea to make users believe that "https://random.paypal-suffix.com" might be legit. I wonder why domains like "paypal-comunication.com" are not registered for nefarious purposes yet.

Here's a sample of different "clickable" URLS you can find in an email from the NSLSC, the Canadian student loans department:

  click.csnpenslsc.ca
  csnpe-nslsc.cibletudes-canlearn.ca
  nslsc.ca
  app.studentlending.ca
  protege-secure.csnpe-nslsc.canada.ca

Important to note that this is a department that manages tens to hundreds of thousands in loans per user, asked users to recreate an account multiple times, on a variety of domains, by providing critical personal info (including SIN), and sent threatening notices demanding payment for nebulous charges that later resolved themselves.

In what way does a password length limit suggest plain-text storage?

In the same way that the best one-way hash algorithms can accept arbitrarily large inputs and produce a constant-sized digest.

True but I thought you’d want to have some size limit regardless, if for no other reason than choking up the connection with a huge one.

Sure, but "some size limit" can be as big as 500 or 1000 bytes. "Choking up the connection" won't be for very long at all. Even on a 2400 baud modem, you're talking only a few seconds to transmit a kilobyte of password. On modern cell networks or especially broadband connections, you pretty much won't choke the connection at all with a 1000-character password.

To add to that, the login page (which contains nothing but two fields for email and password) weighs in at 1.5 MB, so bandwidth clearly is not an issue for PayPal.

Which still doesn't refute the need for a limit, and a large part of why I didn't defend a 24-character limit.

I agree, which was I was only criticizing the point against "there should not be a limit at all" -- I don't know what you're disagreeing with that I said.

One reason why one might have a password length limit (especially such a low one) is because it is stored in a fixed size 'string' field in a database. This used to be a common configuration of authentication mechanisms where the password was stored plaintext. Now, I don't think paypal is _actually_ storing passwords in plaintext.

However, it is the first reason that comes to mind when this kind of limitation exists.

My most generous explanation of this scheme is that, at some point, paypal used plaintext as the backend for authentication. Now when they moved to a better scheme for the backend they never updated the length limit. Then this limit of 24 slowly invaded all code on the front-end of auth and changing it is seen as to big an issue. I'd expect some reasons like 'longer passwords are harder to remember' and 'network performance' are probably used internally as rationalizations for why no one starts trying to fix this.

Alternatively, they could really believe in a 'long passwords are harder to remember' or 'long passwords would induce a lot of performance overhead'. However, as far as I know, there are no reasons that fall anywhere near 'best practice' that would support a password length limit of 24.

Because there's usually not a reason to limit it to something that low.

A previously defined field length on a production database would be a more simple explanation, no?

No because the length of that field is static. Hashing algorithms (at least the ones you should use) will create a static length hash no matter the size of the password.

The only time length matters is if the hashing algorithm has a limit (which is usually pretty high), or if you're storing these values encrypted/plain text.

Hence, the presence of a password limit suggests the used of a fixed length field in a DB that stores values in plain-text.

The passwords being stored encrypted with a fixed length cyphertext would make 24 a weird number. That would suggest something like AES-192. Without storing the IV in the same field. Moreover, encrypted passwords are worse than hashed passwords. Because it means you need to secure the encryption key. Whereas with a salted hash, there is only brute force for recovering plain-text passwords.

Or because you don't want to risk users forgetting very long passwords. (Everyone should be using a password manager, but sadly that isn't the case.) That's generally the reason that limit is set.

That certainly flies in the face of most recent recommendation. Recent NIST guidelines say not to do this, and NIST isn't really known for being adventureous.

The current best practice is for people to use passphrases rather than complicated passwords. For this, a password length limit of 24 is simply not enough.

I'm no advocate of it; just explaining what's very likely their rationale, as opposed to them storing passwords in plaintext. Plaintext password storage still happens, but you wouldn't see that at a company like Paypal. (Plaintext credentials may be unintentionally present elsewhere, like debug logs, but a company like that isn't going to be so incompetent as to store them in plaintext in the database.)

We've literally seen larger companies be more incompetent.

There's no reason PayPal is excluded from this.

Can you show me a larger payment-focused company that's been revealed to be storing passwords in plaintext within the past 5 years? Not saying there's not a ton of incompetence, but that's a very specific level of incompetence.

Why does it have to be payment focused? There's tons of big tech companies that have done this.

Enjoy: https://github.com/plaintextoffenders/plaintextoffenders/blo...

It's not difficult to find them

I'm just saying a company like Paypal which is both massive and dealing with something extremely sensitive (money) isn't going to make such a ridiculous mistake. I'm definitely no fan of theirs; I'm just saying it's silly for the initial poster to speculate the password length restriction is there because they're storing them in plaintext.

Plaintext password storage definitely still is common, unfortunately, but you're not going to see it at a place like Paypal or Bank of America or Stripe in 2020. Or even 2010.

Yeah you're in for a surprise in the future.

I work in the infosec industry, so I've definitely seen some crazy and incompetent shit. But I still don't think Paypal or Stripe would store plaintext credentials.

> The password length limit reduces the quality of passwords, and suggests plain-text storage of passwords

No, it limits the effectiveness of passphrases.

It does not suggest or not suggest plaintext storage.

I’ve been telling friends and family, for at least 10 years, maybe more, the only safe way to go to PayPal, is to type the address into the browser yourself, starting with HTTPS.

Paypal is preloaded, so you're not required to start with HTTPS. https://hstspreload.org/?domain=paypal.com

While that includes Chrome, Safari, Firefox, IE, and Edge that’s not every browser and it’s a really bad habit to get into. Especially as the preload lists are yet another attack surface.

It would be so nice if paypal actually did the same thing. Instead they are training their users to just click on that link in the e-mail.

Reply on news.ycombinator.com