Live data from Hacker News

“We found PayPal vulnerabilities and PayPal punished us for it”

cybernews.com

101–110 of 337 posts

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#101

Earlier quoted context omitted.

> They were created for sincere reasons, and with best intentions. No? They were created by the industry to avoid actually being regulated and are a way to shift liability. That doesn't mean they aren't also beneficial, but that's more a side effect than the intention.

Yes? If we want to be cynical, of course there was a self-serving reason they created the standards -- because fraud, especially "internet" fraud, was on a massive upswing and it threatened this enormous new market of credit card spending. There is no question it's in their self-interest to improve the general condition of transactions.

> If we want to be cynical, of course there was a self-serving reason they created the standards

It's not cynical, it is literally the reason PCI exists.

> Five different programs had been started by card companies... The intentions of each were roughly similar: to create an additional level of protection for card issuers

- https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec...

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#102
post #24

Earlier quoted context omitted.

> but disclosing bugs publically is an addition to your resume Request disclosure on hackerone then. Idk, breaking the law to get a job doesn't seem ok to me.

Full disclosure isn't a crime in the United States, at least.

Hacking PayPal is a crime tho'.

Except for when you play their game, which means: submit bugs via h1 and only disclose if they allow.

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#103

Earlier quoted context omitted.

reading both, looks to me like this is pretty much 2fa. isn't 2fa defined as a "second factor" beyond user:pass? isn't that what this bypass is about?

There is genuine disagreement about whether email qualifies as a second factor. As it is often just protected by a username and password the argument is that it's the same "something you know" factor as a password, or just an obfuscation of the same factor. I will say, that if cybernews have done what they say that they've done, and PayPal are claiming that it's not a concern, then PayPal are clearly in the wrong, an…

also - this image: https://cybernews.com/wp-content/uploads/2020/02/security-ch...

looks like it's not email as the second factor, but your device via SMS

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#104
post #83

Earlier quoted context omitted.

Sorry, but you don't understand what you are looking at. All of HackerOne's information that you cite is about them being PCI-DSS-compliant or having undergone a SOC2 Type 2 audit. Nothing you link to identifies them as a PCI-DSS auditing company. They are not. And the "scans" the PCI-DSS standards refers to are standard pen-test and external vulnerability scans, usually conducted by an accounting company who will ce…

> All of HackerOne's information that you cite is about them being PCI-DSS-compliant or having undergone a SOC2 Type 2 audit. Nothing you link to identifies them as a PCI-DSS auditing company. They are not. Please read the page again. They specifically say you can achieve compliance certification with HackerOne.

We read the page, and even if your claim holds, it is still irrelevant because whatever you quoted is not the same as being a PCI-DSS approved scanning vendor. And even if it was, HackerOne did not perform any scans.

HackerOne offering PCI-DSS approved auditor approved challenges gets you nowhere towards the claims you made in your first comment.

To review:

1. HackerOne would have to be a PCI DSS Approved Scanning Vendor - they are not AFAICT, neither is the CyberNews research team that did the scan AFAICT.

2. HackerOne would have to have conducted the scan - they did not. The CyberNews research team did.

3. The scan that HackerOne did would have to qualify as a PCI-DSS external scan - which ... do you get the part that HackerOne did not do the scan here or not? And nowhere did the CyberNews research team claim they performed a PCI-DSS external scan.

Please at least try to make an argument for your claims

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#105

Earlier quoted context omitted.

GDPR max fine is (iirc) 4% of revenue. So if you are a small fish you will be paying less then the big fish. Also the fines are for wilful failure to comply, if you accidentally broke GDPR then your first offence is going to be more a slap on the wrist then an instant 4%.

Except it says "whichever" is higher, so if they decided to fine you 10 million or 2% of revenue, and your 2% is much lower than 10 million, guess which one you're paying... > Up to €10 million, or 2% of the worldwide annual revenue of the prior financial year, whichever is higher See: https://www.gdpreu.org/compliance/fines-and-penalties/

If you want to get a feel for how GDPR fines vary, https://www.enforcementtracker.com/ keeps a list.

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#106
post #16

Earlier quoted context omitted.

The points associated with a duplicate report depend on the status of the report you get duped to. I assume in this case the original report was Not Applicable.

Oh so an N/A dupe? That sounds plausable.

The policy of the company I worked for was only to dupe to closed issues if those issues were Resolved -- if the duplicate issue was already closed Informational or N/A, we just closed the new one with the same status. This has advantages in avoiding researcher confusion, as illustrated here.

But that was a company policy, not an H1 policy. It's perfectly possible to dupe to a closed issue. (And of course, it's also possible that you get duped to an open issue which is later closed N/A, though that's pretty awkward. You kind of hope for N/A issues to be closed right away, not to stay open for long periods.)

And not duping to closed issues causes other issues -- it meant always having to leave an internal comment citing the other issue that this one was secretly a duplicate of.

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#107

Earlier quoted context omitted.

> Not anywhere on the page you linked. Read the page carefully - it specifically states they are an auditor approved org. Quote from page: “Meet penetration testing requirements for PCI DSS and SOC2 Type II compliance certifications with our auditor-approved penetration testing methodology and Security Assessment Report.[1].” Secondly, PayPal works with HackerOne officially [2] and within the CVSS standards as they c…

What is their certificate number?

> If PayPal’s PCI-DSS compliance certification isn’t revoked then PCI-DSS is a farce.

This comment chain has convinced me that PCI-DSS is a farce.

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#108
The author might as well have sold the exploits for the best offer.

If a company advertises a bug bounty problem but fails to follow through, such company kinda deserves to be hacked. I mean, you are wasting people's time and still getting critical bug reports, probably along with a detailed write-up.

Also, we might also discuss about the fact that for a company that moves (and earns) so much money as PayPal, 30 kUSD is probably very little when compared to the possible outcomes of being hacked.

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#109

Earlier quoted context omitted.

> All of HackerOne's information that you cite is about them being PCI-DSS-compliant or having undergone a SOC2 Type 2 audit. Nothing you link to identifies them as a PCI-DSS auditing company. They are not. Please read the page again. They specifically say you can achieve compliance certification with HackerOne.

We read the page, and even if your claim holds, it is still irrelevant because whatever you quoted is not the same as being a PCI-DSS approved scanning vendor. And even if it was, HackerOne did not perform any scans. HackerOne offering PCI-DSS approved auditor approved challenges gets you nowhere towards the claims you made in your first comment. To review: 1. HackerOne would have to be a PCI DSS Approved Scanning Ve…

“SATISFY COMPLIANCE CERTIFICATION REQUIREMENTS

Meet pentest requirements for PCI DSS, SOC2 Type II, and HITRUST compliance certifications.” [1]

[1] https://www.hackerone.com/product/pentest

Re: “We found PayPal vulnerabilities and PayPal punished us for it”

#110
post #97

Earlier quoted context omitted.

> I would guess that, contrary to your implication, they are not an approved scanning vendor. If this is the case then it really does not speak to the characteristics of PCI-DSS and your comment just seems wrong. Actually this makes a pretty good case for this regulation being a joke. They clearly aren’t up to the responsibility of being a payment processor and are leaning on the law to sustain their business rather…

Why does the regulatory body get to approve who and what can scan implementations of their security scheme? It seems like the ideal auditor and scanning software, in PCI DSS's eyes, would be the one that just barely checks the boxes for minimum security requirements. Poking too hard at their security scheme would reveal how lackluster it is but they still need someone to poke at it to prove compliance. Being able to…

> Why does the regulatory body get to approve who and what can scan implementations of their security scheme?

Because it's a scanner for PCI-DSS compliance, not a scan for security issues.

They do not fear that unapproved scanners will be more strict than approved scanners, they fear they will be less strict.

Post reply on HN