Comment by andrewstuart2

Comment by andrewstuart2 4 days ago

11 replies

View on Hacker News

This is more of a fundamental issue with the way we rely on DNS to secure *gestures wildly* all the things. The fact that domains can expire and be registered by someone new allows the new owner to do almost anything the old owner could have done when it comes to anything trusting email addresses, or anything else relying on DNS (ACME certs) for authentication.

It's great for "do they own this right now" validation and that's what we use it for, but beyond that links will be saved, email addresses will be added to databases and address books alike, and that's more or less a reality of most systems. For example, my snail mail (and occasionally packages) is still mistakenly delivered to my former addresses from time to time just because it's hard to track who has that address, and update it everywhere. The same goes for internet infrastructure.

simondanerd 4 days ago

I was able to take over an Instagram account because I received a password reset email to a domain catch all address that I'd set up years ago. Turns out it was a whole brand, but they refuse to change the email address and don't understand that I'm going to shut it all down. It totally makes my site look bad (it was an adultish brand and I was working on a community project) and I now have the power (and ability to do whatever with the account and any other that I happen upon with an email at that domain.

Reply View 0 replies
jeroenhd 3 days ago

With OIDC, that's what the `sub` identifier is for. Apparently, this changes for 0.04% of accounts (according to "a staff engineer at a major tech company" quoted in the article), but it's what Google tells you to use to identify a user. When a domain expires and you re-register for OIDC with Google, the `sub` claim will differ and the application should refuse your login attempt.

If the `sub` claim does indeed change for no good reason, that's a bug on Google's side, but I can't find anything online to corroborate that claim. The sub value changing when accounts are recreated could be a pain for large companies to deal with, but other than that the solution is pretty simple.

There are no good alternatives for email addresses that are also human readable, unfortunately. Some web3.0 cryptocurrency projects do encryption based authentication that solves this problem (but makes your accounts impossible to recover if you lose your key file). Passkeys/WebAuthn also try to solve this problem by foregoing the entire username requirement, but websites still ask for email addresses just in case.

Reply View 1 reply
  • [removed] 3 days ago
    [deleted]
    Reply View 0 replies
Pxtl 4 days ago

I disagree. DNS stores enough information in WHOIS to see if ownership has changed, it's not DNS' fault that nobody looks.

Probably the least-wrong thing to do with current DNS is to have authentication servers keep track of the WHOIS UpdatedDate of email domains. If a WHOIS UpdatedDate is newer than the corresponding user's linked email address verification, that user's email address is no longer trusted. Next time they log in ask them to update or re-confirm their email address, and if they try to password reset they can't use an unconfirmed email address.

Yes that's more tricky work. Authentication is hard. Nobody should be DIYing authentication anymore in this day and age, it's just too much.

Reply View 6 replies
  • niij 4 days ago

    What does this protect against? If the WHOIS changes because someone new buys the domain then they could simply receive this reset emails, no?

    Reply View 2 replies
    • Pxtl 4 days ago

      Yes, but the user had to go through the process of "wait do I still have that email address? Did I receive it?"

      Like, let's say I have an email address pxtl@example.net, and I used that to register an account on service.com, and example.net goes under.

      In theory I know that this event has occurred, I no longer have access to my email address at pxtl@example.net.

      So I log into my service.com account and get told "hey your email was pxtl@example.net - example.net has changed ownership. Is that still your email?" and I'll say "no" and put in a new email.

      Or maybe I don't realize that example.net is gone. So I try to verify the account, find that I'm not receiving the email, and realize my mistake and set up a new email account, and click the button that says "I did not receive the email". The authentication server can prevent this window of time being an attack vector by forcing a delay between email validation and password reset, and by de-validating the email address (and treating it as a red flag on the whole domain) if the user clicks "I did not receive the email" a few minutes after the email address has been verified.

      And if I forget my password and try to reset password on service.com using my unverified pxtl@example.net? "example.net had an ownership change since this email address was registered, please use another means to reset your password like SMS". Which is the main benefit of this process. Which I know doesn't require full verification.

      Now, obviously the WHOIS updateddate is a noisy signal. Ideally the DNS system would expose a more granular ownership-change date - for example, gmail.com lists a WHOIS updateddate of July 11th 2024. UpdatedDate isn't supposed to change with every renewal but lots of things aren't supposed to happen.

      Reply View 1 reply
      • Pxtl 4 days ago

        Following up on this: Apparently my knowledge is out-of-date.

        WHOIS has been superceded by RDAP, and RDAP provides event data for registration and re-registration. So even better!

        edit: it doesn't seem like registrars actually do re-registration, and many cctlds don't even use RDAP yet.

        Reply View 0 replies
  • mixdup 4 days ago

    You can put whatever you want in WHOIS, including just replicating the information that was there previously. What if the WHOIS email is an email on the domain in question?

    Maybe registrars could set a unique ID per registrant, and if a domain expires and is purchased by a different entity/account than the previous one the registrant GUID is refreshed. That could then be a signal that all previous reliance on the DNS of the domain name should be null and void

    Reply View 1 reply
    • Pxtl 4 days ago

      This led me to go do a deeper dive.

      1) WHOIS has been partially replaced by RDAP although many ccTLDs don't support it yet (notably .au and .us for example). Spec for RDAP query results:

      https://datatracker.ietf.org/doc/rfc8977/

      2) RDAP does specify that the registration date should be of the last time registered - if a domain has lapsed and picked up by somebody else it's supposed to use the verb "reregistered". But of course, you're depending on the registrar to do that. It does look like "registered" is properly followed - I looked into some known cases of poached lapsed domains and checked their RDAPS and the registration date corresponds to the date the domain drop-caught but no past expiry or re-registration is listed (example[1]).

      3) Either way, don't use the content of the WHOIS/RDAP, just the dates.

      [1]https://www.adrforum.com/domaindecisions/1967817.htm

      Reply View 0 replies
  • [removed] 4 days ago
    [deleted]
    Reply View 0 replies
gmuslera 4 days ago

At least it counts as a new category on the "It's DNS fault" list.

Reply View 0 replies