India made a positive step last year with dedicated zones for financial institutions which they must use for everything (web presence, emails, the lot): .bank.in for banks, and .fin.in for others. Great improvement.
Nice, although I wish it was just the web: I've gotten an SMS from a bulk messaging provider telling me to call [phone number that isn't documented anywhere] followed by "Hello, it's [name of bank]. To verify your identity, please give us your name and read the back of your credit card".
It was real, but completely indistinguishable from a scam.
In response to TRAI's regulatory initiative, the '1600' numbering
series has been assigned by the Department of Telecommunications (DoT)
for allocation to entities in the Banking, Financial Services and Insurance
(BFSI) sector, and Government organisations to clearly distinguish their
service and transactional calls from other commercial communications.
Combine that with constant login expiration triggering random authetication pop-ups, it becomes nearly impossible to defend against phishing... ... because the real thing looks indistinguishable from a scam [...] All an attacker needs to do is write a website with a password box and the company logo. The URL doesn't matter at all because users learn to ignore it.
But at the bedrock of this focus on “culture”—no matter the industry—is its bellicose insistence that the humans intertwined with systems must focus more on security (or “safety” in other domains). [...] Hence, we see an obsession with preventing users from clicking on things, despite the need in their work to click on many things many times a day. One might characterize the cynosure of infosec “security culture” as preventing people from clicking things on the thing-clicking machine [...]
Discussions about culture offer little impact without being grounded in the reality of the
dynamic, complex systems in which humans operate.
When I first read this, it was so "d'uh!" to me that I thought that anyone who really thinks about security, especially professionally, would already have this internalised. but, uh, apparently not.
I appreciate the angle of not wanting to shame the guilty... But I will! Workday is TERRIBLE for this. Even including really phishy urls in genuine email comms.
I was surprised that Kanidm (a self-hosted OIDC provider that aims to raise the security floor) recommends a separate domain as the "safest" place to host your IDM:
Running Kanidm on a separate top-level domain makes it much easier to restrict changes that could affect your IDM infrastructure. For maximum security, your Kanidm domain name should be a subdomain of a top-level domain (or domain under a public suffix) that has no other services assigned it. In this example you own example-auth.example which you would operate in parallel to example.com.
They also say hosting on a subdomain of your main domain is fine, but I was surprised there wasn't more concern given to the phishing risk of choosing a separate domain. Especially for auth, as mentioned in the article.
I think it's also worth considering how advice like this promulgates. Are there ways we can make it safer by default to host auth on the main domain (or a subdomain of it) without requiring arcane knowledge of what actions on other domains could put it at risk?
The problem there is browser vendors having the wrong priorities (due to existing setups, ads, tracking and the likes)
So that gives us things like "same site" not actually being the site bla.example.com but it AND all parent domains (example.com) as far as cookies and the likes go.
I see this alot at my current and several of my previous employers where a myriad of new, separate domain names are registered for different things - both internal services as well as external efforts. I'm a technologist, so i'm primed to be skeptical about link and domains to be clicked...but other folks in the orgs that i worked for would be genuinely confused because they've been slowly taught that some links do not exist under their root corporate.COM. Its certainly not a technical issue so much as a training and process opportunity. Training both for the employees doing the clicking, but also for the teams that sponsor these separate websites that choose these separate domain names. And process, because either the sponsors for these new, separate websites either don't know that a process might exist for requesting new subdomains for their project, or they know the process but hate it and circumvent it. None of this is overtly complex...there simply needs to be a willingness to do things right...and the sad thing is that if/when done right, it actually may save a little bit in cost savings (e.g. less training needed, less security scan tool costs, less costs for managing requests that are outside the normal subdomain requests, etc.). Ok, sorry, i guess i just went off on a mini rant myself. Sorry, not sorry! :-)
I think this ship has sailed. Companies rely so much on "no code" platforms and other SaaS cloud garbage that they are no longer capable of keeping everything on their own domain. On top of that, a lot of companies "outsource" things like customer satisfaction, shipping notifications and even payment methods (the latter probably being a good thing for security), all of which kind of have to run on external services.
A lot of external services run on CNAME. Many payment flows run in iframe (which has some drawbacks, sure) then open something under the card's payment processor domain (if applicable — IBAN-based flows might not need a card) then maybe open something under your bank's domain. Here the third party involved at least is a company with their logo on your payment card, not just a random phisher.
And yeah, if you need to send a link to a third-party domain, at least optionally laundering it through your own domain with a redirect can be a good idea.
Shipping notifications… you'd better do a hand-off with verifiable tracking number, but then still, Backmarket is somehow better at sending notifications (as a marketplace intermediary) based on scraping UPS tracking than UPS at sending useful notifications based on their own system!
chrismorgan | 18 hours ago
India made a positive step last year with dedicated zones for financial institutions which they must use for everything (web presence, emails, the lot): .bank.in for banks, and .fin.in for others. Great improvement.
(Actually, not sure if .fin.in is mandatory. But .bank.in is, they were given about six months to complete the transition so they all switched at roughly the same time.)
[OP] maurycy | 17 hours ago
Nice, although I wish it was just the web: I've gotten an SMS from a bulk messaging provider telling me to call [phone number that isn't documented anywhere] followed by "Hello, it's [name of bank]. To verify your identity, please give us your name and read the back of your credit card".
It was real, but completely indistinguishable from a scam.
chinmay | 16 hours ago
Bank phone numbers are also mandated to start with 1600
coby | 13 hours ago
Is the converse true as well, that only banks can have numbers that start with 1600?
chinmay | 13 hours ago
Yes
strugee | 17 hours ago
See also Thanks FedEx, This is Why we Keep Getting Phished (previously, on Lobsters), as well as Stop Giving Impossible Advice: Telling People to Watch Out for SUSPICIOUS EMAILS is Nonsense.
connorboyle | 8 hours ago
Cloudflare, of all companies, did this too (also on Lobste.rs)
zaphar | 17 hours ago
It's so bad that sometimes I and my colleagues report the official emails as phishing emails just to make the point.
jbauer | 16 hours ago
At my company we've literally had multiple security professionals mark official Microsoft emails as junk because they looked so much like phishing.
lake | 17 hours ago
This reminds me of Security Chaos Engineering by Kelly Shortridge:
When I first read this, it was so "d'uh!" to me that I thought that anyone who really thinks about security, especially professionally, would already have this internalised. but, uh, apparently not.
olliej | 16 hours ago
I was going to link to Troy’s fedex post
The number of companies that seem to go out of their way to train users to click on phishing links is stunning.
I think the only fix is to make companies lose liability protection if they don’t follow sensible rules like this
eyesinthefire | 16 hours ago
I appreciate the angle of not wanting to shame the guilty... But I will! Workday is TERRIBLE for this. Even including really phishy urls in genuine email comms.
exhale | 6 hours ago
I was surprised that Kanidm (a self-hosted OIDC provider that aims to raise the security floor) recommends a separate domain as the "safest" place to host your IDM:
(Emphasis in original)
They also say hosting on a subdomain of your main domain is fine, but I was surprised there wasn't more concern given to the phishing risk of choosing a separate domain. Especially for auth, as mentioned in the article.
I think it's also worth considering how advice like this promulgates. Are there ways we can make it safer by default to host auth on the main domain (or a subdomain of it) without requiring arcane knowledge of what actions on other domains could put it at risk?
bookworm | 5 hours ago
The problem there is browser vendors having the wrong priorities (due to existing setups, ads, tracking and the likes)
So that gives us things like "same site" not actually being the site bla.example.com but it AND all parent domains (example.com) as far as cookies and the likes go.
connorboyle | 8 hours ago
I'm a bit disappointed that https://funnies.maurycyz.com/memes/crow_hobbies.jpg turned out to be a dead link
[OP] maurycy | 7 hours ago
Should work now.
mxuribe | 14 hours ago
I see this alot at my current and several of my previous employers where a myriad of new, separate domain names are registered for different things - both internal services as well as external efforts. I'm a technologist, so i'm primed to be skeptical about link and domains to be clicked...but other folks in the orgs that i worked for would be genuinely confused because they've been slowly taught that some links do not exist under their root corporate.COM. Its certainly not a technical issue so much as a training and process opportunity. Training both for the employees doing the clicking, but also for the teams that sponsor these separate websites that choose these separate domain names. And process, because either the sponsors for these new, separate websites either don't know that a process might exist for requesting new subdomains for their project, or they know the process but hate it and circumvent it. None of this is overtly complex...there simply needs to be a willingness to do things right...and the sad thing is that if/when done right, it actually may save a little bit in cost savings (e.g. less training needed, less security scan tool costs, less costs for managing requests that are outside the normal subdomain requests, etc.). Ok, sorry, i guess i just went off on a mini rant myself. Sorry, not sorry! :-)
sjamaan | 2 hours ago
I think this ship has sailed. Companies rely so much on "no code" platforms and other SaaS cloud garbage that they are no longer capable of keeping everything on their own domain. On top of that, a lot of companies "outsource" things like customer satisfaction, shipping notifications and even payment methods (the latter probably being a good thing for security), all of which kind of have to run on external services.
k749gtnc9l3w | 38 minutes ago
A lot of external services run on CNAME. Many payment flows run in iframe (which has some drawbacks, sure) then open something under the card's payment processor domain (if applicable — IBAN-based flows might not need a card) then maybe open something under your bank's domain. Here the third party involved at least is a company with their logo on your payment card, not just a random phisher.
And yeah, if you need to send a link to a third-party domain, at least optionally laundering it through your own domain with a redirect can be a good idea.
Shipping notifications… you'd better do a hand-off with verifiable tracking number, but then still, Backmarket is somehow better at sending notifications (as a marketplace intermediary) based on scraping UPS tracking than UPS at sending useful notifications based on their own system!
patchunwrap | 4 hours ago