Hacker News Reader

Comment by basicplus2 | Hacker News Reader

"instead of actually deleting it, they simply appended '1000' to both the username and the email address. anyone could thus create an email address with that suffix and request a password request to access my info."

View on HN

not an issue as long as there is no tld which ends with 1000 though

Most likely the 1000 is appended to the local-part of the email address, not the domain, as any tool they are using for changing details most likely validates emails somehow.

The email address doesn’t really need to be valid though. I have an old client that appended ‘|disabled’ after the email address (and torched the password) when “deleting” accounts because they needed them in the DB for audit logging.

Unless someone figures out how to register a domain ending in ‘.com|disabled’ I’m not sure how someone would be able to access those accounts.

Every week we see multiple articles about security researchers who abuses some part of the tech stack to do something weird that shows the danger in this sort of thinking.

I believe it's easy to spoof emails from the .com|disabled domain. Receiving messages, I agree, seems harder. Maybe spoof an unencrypted DNS response at the right moment? No need to actually register a domain when DNS is spoofable.[1]

If you really need to use a hack like that to disable an email, consider adding some code to your email sending logic that skips such email addresses (and always use that logic). Otherwise clever hackers have a foothold to try their tricks against.

[1] https://en.m.wikipedia.org/wiki/DNS_spoofing

My guess would be that they don't want to have that email accidentally used, but they would have a check in the codepath anyway, because no-one wants to see its logs spammed with myriads DNS errors when this can be avoided. And in fact, if a DNS error shows up in the logs, devs would know that somehow their code path is not completely safe, so that change on the email is perhaps a way for them to ensure that the disabled account is indeed seen as disabled by their code in every situation.

A lot of people are complaining about NYT approach, but perhaps their only fault - if one consider that not deleting for good an account is not an issue, and it seems to be a common practice in the industry - is to not use a transaction when disabling user accounts (disable email -> disable account), which is perhaps difficult with NoSQL setups?

In-band signalling has always been error-prone. It's never worked and it never will.

"the number was appended to local-part, not the domain. I found out by going back to a tab where my session was still valid but the account dropdown had updated with the new name. Profile settings revealed the email."

Completely wrong, dont just munge someone's email and hope it wont work, we literally have domains for this kind of stuff. https://www.iana.org/domains/reserved

Chances of com1000 being delegated is low.

Why would it need to be designed? Email delivery depends on DNS, which is unencrypted and spoofable. Spoofing emails is also doable.

If the dns lookup on a com1000 domain fails, the email won’t go anywhere.

Correct. But if a DNS response for that domain is spoofed. It will.

DNS is a very old protocol that still has lots of problems and mitigations like DNSSEC are only partially deployed.

Email is an inherently insecure medium. If an attacker can compromise the DNS responses for your mail server, you're hosed.

Reply on news.ycombinator.com