4 ms·
"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 su
by basicplus2 6y ago
"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."
- deleted 6y ago[deleted]
- polote 6y agonot an issue as long as there is no tld which ends with 1000 though
- bagacrap 6y 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 6y ago[deleted]
- diggan 6y 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 6y 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 6y 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 6y agoIn-band signalling has always been error-prone. It's never worked and it never will.
- waltpad 6y 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 6y 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 6y agoChances of com1000 being delegated is low.
- thanksforfish 6y agoWhy would it need to be designed? Email delivery depends on DNS, which is unencrypted and spoofable. Spoofing emails is also doable.
- loopdoend 6y agoIf the dns lookup on a com1000 domain fails, the email won’t go anywhere.
- thanksforfish 6y 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 6y agoEmail is an inherently insecure medium. If an attacker can compromise the DNS responses for your mail server, you're hosed.