Hacker News Reader

Hacker News

Comment by kragen | Hacker News Reader

Parent Full thread

kragen

Is this a legitimate alternative domain name for PayPal, or is it a parody or phishing site? It's not paypal.com.

Apparently it's legit: https://news.ycombinator.com/item?id=45250319

View on HN

It’s so dumb because they are training everyone to be phished by scammers.

I was learning about cold email marketing earlier this year, and it's all about learning to be a spammer:

- Registering lots of domains (launchmyapp.com, trymyapp.com, myapp.info, gomyapp.biz, etc.)

- setting up a limited number of mailboxes per domain

- warming email accounts up for 2 weeks by signing up for a service that sends to and receive messages from your accounts

- setting up a meta inbox to track messages sent and received across all of your accounts

Now pretty much every domain that isn't myapp.com looks like a spammer's domain to me.

> cold email marketing earlier this year, and it's all about learning to be a spammer

You sound surprised. What's the difference between "cold email marketing" and "spamming"?

Cold email marketing can be highly targeted. Like, reaching out to your 5 potential customers and telling them about your service in terms of their specific context.

Spamming is not that.

You're right, although I think I'd just call that sending a few emails. Cold email marketing as a practice includes learning how to avoid spam filters and avoiding being detected, and it's unapologetically spammy.

One term ist slightly longer

They do the same with emails. I've got emails from them with links to paypal-communication.com. It's stupid.

I once got an email from PayPal where it claimed that I had been double-charged on my PayPal account, and they also misspelled my first name. It was a legit email, but it sure as shit didn't look like it.

Nice of them to cause confusion to make phoning easier. No, corp.paypal.com/news or PayPal.com/corp/newsroom etc weren’t a good idea. I’d love to hear how decisions like this get made.

This approach (using a separate domain for content that isn't part of their service itself) has security advantages-- for example, this way a compromise of their news site CMS can't expose users' PayPal session tokens.

It's decently common for websites to do this-- this is the same reason why Github Pages is hosted at github.io rather than github.com, and why static blobs are at githubusercontent.com. Those have a somewhat different threat model than PayPal's news site (hopefully PayPal isn't letting any random person add news stories...), but the premise is the same: if the thing does not need authentication tokens for the main service, make it so that it's impossible for it to get them.

(You could get some of the same effect by scoping your cookies to a specific subdomain rather than allowing them to apply to all subdomains, but (1) that's not always how you want to structure your site, and (2) it's really easy to mess up and inadvertently scope a cookie too broadly (or for the browser to misbehave and send to subdomains anyways, which was the default behavior of one very prominent browser for a really long time). Using a different domain entirely sidesteps all of this completely.)

Maybe I'm missing something but you can't separate you're session and authentication with a different subdomain? Eg. My session on corp.paypal.com would be locked down to solely corp.paypal.com.

From a practical sense, what different does a subdomain and a dedicated domain offer if you're managing your certs correctly?

You can, but a lot of people lack the discipline to do so correctly. I'd prefer them to use corp.paypal.com, but as a security guy it's easier to just get them a separate domain and let them have their less-secured stuff completely isolated.

You can, but is difficult and prone to errors. Separate domains solve the root cause of the issue. The alternative is an entry on the public suffix list.

Which would not be easy to get, considering PayPal is not running a public suffix.

you can request entries on it, the list is not just for TLDs

Yes, but the list is for public suffixes, i.e. domains under which users can get their own subdomains.

From my point of view, a possible compromise of their news site CMS sees like a much less serious threat than phishing, so this seems like a bad tradeoff. If you're worried that cookie scoping will get broken, maybe you could have the news site CMS raise an alert if it sees PayPal-session-token cookie names.

This is common for corporate investor relations sites.

They serve entirely different audiences and are usually separately managed for the product sites, it’s also common for the latter to be blocked by the companies which are the target audience for the former.

I’ve always felt that we need a tool to be able to answer such a question.

My bank also uses a different hyphenated domain name on emails… another use case could be to check for legit social media profiles cause fakes are popular too and may not be discernible for regular grass touching not-so-online in 2025 individual.

Maybe we could introduce the concept of subdomains. Paypal could, for example, have a corp.paypal.com address that points to their corporate blog. I know, a bit out there, but maybe DNS2 will ship with this feature.

With subdomains, you might leak cookies accidentally or maliciously to the root domain. They are not as separated as real domains are.

Then don't put anything on the root domain and use www.paypal.com for the main operations. corp.paypal.com's cookies are separated from www.paypal.com's.

But paypal.com's cookies are shared with corp.paypal.com and, depending on headers and fields, possibly vice versa.

My browser lists 8 .paypal.com cookies and 2 www.paypal.com cookies when I visit www.paypal.com. Those cookies are shared with https://fastlane.paypal.com/ (some random subdomain I found online).

They can separate those cookies out, of course, but they don't need to if they use separate domains and the cheapest work is work that doesn't need doing.

They also seem to own paypal.ai which mcp.paypal.com redirects to the docs of it could also just be a branding thing.

www.paypal.com can create cookie for paypal.com and that cookie will be sent for corp.paypal.com requests. And vice-versa, of course.

EV Certs used to do exactly that for me, that is until browser stopped make the visuals of it special. Don't think it would be even viable today given the short expiry (which is a good thing) of TLS certs necessary for browser

https://en.wikipedia.org/wiki/Extended_Validation_Certificat...

You can still do all the checks you need, they're right there in the connection properties. This website is OV-certified (not EV) to PayPal, Inc. in San Jose by DigiCert Inc.

You do need to know what US state PayPal is registered in for them to work, of course, as proven by https://arstechnica.com/information-technology/2017/12/nope-... during the time EV certificates were still considered special.

I don't see why EV wouldn't be viable. ACME can work with any certificate. A certificate authority can just sign new certificates every week at the request of an authenticated ACME client. The biggest issue with this workflow is the CA's billing flow optimised for the "pay once, hand over a file once" workflow.

I talked about introducing a notability criteria in the US, and other jurisdictions where duplicate registrations are possible. The Chrome people weren't interested.

Shouldn't be an issue to deliver two certificates an short lived one for TLS, an long lived one for the identity

WHOIS used to be semi useful, though most records tend to be redacted for the average user now.

`dig` on DNS also, if it resolves to the same IP as paypal for example, that adds confidence. Though again, nowadays less useful due to a lot of things being behind Cloudflare.

Reply on news.ycombinator.com