Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Critical PayPal Security Hack: Multiple Thefts Now Reported–Check Your Settings

forbes.com

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Critical PayPal Security Hack: Multiple Thefts Now Reported–Check Your Settings

#61

Post by aaomidi »

humaniania wrote: post #59
aaomidi wrote: post #36

Earlier quoted context omitted.

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.

Re: Critical PayPal Security Hack: Multiple Thefts Now Reported–Check Your Settings

#62

Post by numakerg »

johndough wrote: post #50
rocqua wrote: post #25

Earlier quoted context omitted.

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

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

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.

Re: Critical PayPal Security Hack: Multiple Thefts Now Reported–Check Your Settings

#63

Post by luckylion »

carapace wrote: post #42
herendin2 wrote: post #27

Earlier quoted context omitted.

No, the journalist could easily find independent evidence that suggests the corporate statement is bullshit. It should be challenged and ridiculed. That is the journalist's duty, and they failed. Their job is not to be a copy and paste machine for company press releases.

I agree with your first and third sentences, but not your second.

You don't think they should challenge a company's claim, or should they, but not in the same article?

Re: Critical PayPal Security Hack: Multiple Thefts Now Reported–Check Your Settings

#64

Post by meowface »

aaomidi wrote: post #61
humaniania wrote: post #59

Earlier quoted context omitted.

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.

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.

Re: Critical PayPal Security Hack: Multiple Thefts Now Reported–Check Your Settings

#65

Post by rocqua »

beamatronic wrote: post #29
rocqua wrote: post #25

Earlier quoted context omitted.

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

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.

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.

Re: Critical PayPal Security Hack: Multiple Thefts Now Reported–Check Your Settings

#66

Post by rocqua »

meowface wrote: post #64
aaomidi wrote: post #61

Earlier quoted context omitted.

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.

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.

Re: Critical PayPal Security Hack: Multiple Thefts Now Reported–Check Your Settings

#67

Post by rocqua »

humaniania wrote: post #34
rocqua wrote: post #25

Earlier quoted context omitted.

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

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

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.

Re: Critical PayPal Security Hack: Multiple Thefts Now Reported–Check Your Settings

#68

Post by rocqua »

aaomidi wrote: post #61
humaniania wrote: post #59

Earlier quoted context omitted.

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.

Re: Critical PayPal Security Hack: Multiple Thefts Now Reported–Check Your Settings

#69

Post by carapace »

luckylion wrote: post #63
carapace wrote: post #42

Earlier quoted context omitted.

I agree with your first and third sentences, but not your second.

You don't think they should challenge a company's claim, or should they, but not in the same article?

It's not the journalist's duty to ridicule anyone. Jon Stewart's "The Daily Show" was very entertaining, and even somewhat informative, but I think he would be one of the first to say that it wasn't journalism. I don't like corporate bullshit lingo either but when that's what they say as their formal statement to the press then relaying it is the journalistic duty.

It's one thing if the company is outright lying, but PR blather doesn't really count (for all that it's pointless and annoying.) In any event, yeah, if they want to editorialize, that's fine but it's done in a separate "Editorial" section. ( https://en.wikipedia.org/wiki/Editorial )

Re: Critical PayPal Security Hack: Multiple Thefts Now Reported–Check Your Settings

#70

Post by floatingatoll »

lxgr wrote: post #28
AdmiralAsshat wrote: post #26

Just as a PSA, it wasn't until I looked at one of these articles in the last few days about PayPal that a screenshot showing how to enable 2FA demonstrated that TOTP-based authenticator apps are now allowed. For the longest time, PayPal was only allowing 2FA SMS after they chucked their old physical security keys. Anyone who's been stuck on SMS may wish to login and switch over to TOTP.

I tried when they introduced that and gave up on it again: There is no way to mark a device as trusted, and I'm certainly not opening my 2FA app for every single login/payment. Also, this is 2020, where is WebAuthN? That would at least make the constant 2FA a bit more bearable.

How many times per year do you pay someone with PayPal?
Post reply on HN