Comment by solatic | Hacker News Reader

Comment by solatic | Hacker News Reader

A lot of people advise ways of locking down name changes, but this doesn't really solve the problem. I'm sure there's someone out there whose first name is actually Jira.

I worked for $company where customer dashboards were set up on a wildcard - https://*.$company.com, e.g. https://foo.$company.com. Guess what happens when someone picks a dashboard slug that conflicts with an actual record, like `www` or `blog`? Their dashboard becomes completely inaccessible. Of course, the setting to change the prefix is also on https://$dashboard.$company.com, so the customer is unable to fix it themselves and requires support. Of course, support's tools don't expose the ability to change the $dashboard prefix directly...

Figuring out how to build the denylist isn't really trivial. Of course, there's pre-existing DNS entries. Then there's pre-existing $dashboard prefixes that already exist. Then there's dirty language, Unicode symbols, Punycode (i.e. xn-- prefixes)... then there's setting up redirects from the old prefix and reserving it so that nobody can claim it in the future...

I'm not surprised Slack has holes here, it's a fundamentally hard problem.

Zendesk for example puts their customer dashboards on a direct subdomain of their own main domain. They allow people to use their own domains as well. To use your own domain you have to make it a CNAME for the subdomain that they gave you. https://support.zendesk.com/hc/en-us/articles/4408838571930-...

I think it’s better to do like GitHub and Shopify and many others do. Have a separate domain at least that customer pages are made subdomains of.

GitHub uses GitHub.com as their own domain, and they use GitHub.io as the pages domain with subdomains for users.

Shopify uses Shopify.com for their own site and myshopify.com for customer subdomains.

The main advantages of using a separate domain for customers include:

- You don’t have as many pre-existing or future subdomains that you want for yourself. (You still need to filter so that people don’t use offensive words or misleading words etc.)

- You can have that domain added to the Public Suffix List, which avoids some potential problems you might otherwise run into https://publicsuffix.org/

Also if you set cookies in your app with the scope of your main domain with the hope that they are visible to all of the subdomains you provide for your customers, these cookies are also accessible by 3rd party services that use your subdomains.

So if you run acme.com and give our subdomain to your clients you could end up with client1.acme.com and client2.acme.com. You decide to store cookies on acme.com. The. You decide that you will use SupportCorp’s helpdesk software and host it on support.acme.com. If a logged in user goes to support.acme.com they will send their cookies to SupportCorp’s servers. This might include session ids and other highly sensitive info.

My partners work has an employee named 'Admin'. IT struggles with what to do thee.

huh, real life Bobby Drop Tables, huh? Wonder what name would cause the most damage to flimsy tech while still sounding like a relatively normal name?

I have met a few Admins in my life and, needless to say, there's all sorts of things they have to work around to do normal things online. For example, set the first name to "Admi" and "N" as the middle name to be able to receive a package. And good luck looking them up on places like LinkedIn or Facebook that require but do not accept their actual name.

It's not exactly a common Muslim first name, but it's not unheard of.

I’ve worked with someone named True, who, when I went to go add her to some event or another, something along the way helpfully changed it to “TRUE.”

I also worked with a guy whose last name was Null. His email was null@ for a period of time.

Radiolab did an episode about people in this pickle. https://radiolab.org/podcast/null

he should have married an Indian and named a child Dev. :)

You're really going to make excuses for Slack here? 'o'/'о' is just about the easiest possible homograph attack (https://en.wikipedia.org/wiki/IDN_homograph_attack) that there is:

> When it was his time to leave, McKay swapped out his existing profile picture for one that resembled an angrier version of Slackbot’s actual icon. He also changed his name to “Slackbot.” You can’t just change your name on Slack to “Slackbot,” by the way, as the service will tell you that name’s already been taken. It does work if you use a special character that resembles one of the letters inside Slackbot, though, such as replacing “o” with the Unicode character “о.”

And in fact, this exact pair of English/Cyrillic was used in one of the first published homoglyph attacks: https://web.archive.org/web/20200102175251/http://www.cs.tec... back in 2001!

In 2022, Slack had a valuation of something like $20b and had been in operation for almost a decade. And their business is username-based software for people who need security ie. organizations/businesses.

Limit usable characters, and just literally check the page doesn't resolve already before allowing the change. Customers will never be locked out and characters can't impersonate others.

If you want to allow some symbols you can either whitelist or check if usernames are an appropriate levenshtein distance away from core names (like say slackbot) and either ban such things or flag to a human "hey this could be an issue".

It's fundamentally hard to stop everything, but it's not hard to stop the biggest issues.

> just literally check the page doesn't resolve already before allowing the change

It's a wildcard DNS record, it always resolves, even if it's not saved in the system.

There's a general rule of thumb: when someone on HN tells you to "just" do something, they generally underestimate the amount of effort involved in doing it properly.

It’s not hard to check, I did this recently for a script. I just resolve “(25 generated random chars).example.com” and if “interesting-subdomain.example.com” resolves to the same, then I know that the interesting one is actually only resolving because of a wildcard. If it resolves differently I know it’s taken by a real record.

In this particular case, the wildcards all intentionally resolved to the same address, regardless of whether or not they were already taken. Business logic was handled by looking at the Host header.

"Don't have colliding fundamentally different namespaces" is not really a hard problem to resolve in this case, though.

Reply on news.ycombinator.com