5 ms·
not an issue as long as there is no tld which ends with 1000 though
by polote 7y ago
not an issue as long as there is no tld which ends with 1000 though
- bagacrap 7y ago"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."
- deleted 7y ago[deleted]
- diggan 7y agoMost 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.
- yaur 7y agoThe 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.
- thanksforfish 7y agoEvery 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 https://en.m.wikipedia.org/wiki/DNS_spoofing
- jrockway 7y agoIn-band signalling has always been error-prone. It's never worked and it never will.
- waltpad 7y agoMy 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?
- hobs 7y agoCompletely 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 https://www.iana.org/domains/reserved
- gruez 7y agoChances of com1000 being delegated is low.
- thanksforfish 7y agoWhy would it need to be designed? Email delivery depends on DNS, which is unencrypted and spoofable. Spoofing emails is also doable.
- loopdoend 7y agoIf the dns lookup on a com1000 domain fails, the email won’t go anywhere.
- thanksforfish 7y agoCorrect. 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.
- gruez 7y agoEmail is an inherently insecure medium. If an attacker can compromise the DNS responses for your mail server, you're hosed.