Can you steal a user's identity if you gain their old domain name?

Asklemmy@lemmy.ml – 6 points – 1 years ago

Just a random thought experiment. Let's say I have my account on a lemmy instance: userA@mylemmy.com. One day I decide to stop paying for the domain and move to userA@mynewlemmy.com, and someone else gains it and also starts up a lemmy instance.

If they make their own userA@mylemmy.com, how do federated instances distinguish who's who?

Have I misunderstood the role of domain names in this?

I imagine it works exactly like email where it is possible to inherit someone else's expired domains.

Checking out the relevant specifications: ActivityPub and WebFinger

Both of them identify users by URL, there is no numeric ID, UUID, or public key.
Using IDs or UUIDs would not be secure since the imposter could just copy the ID from the previous user as well as the username and domain name.
Verifying identity would necessitate the user having a public key as their unique identifier, and federated servers performing a challenge-response that requires the user to have the corresponding private key for that public key.

In conclusion, it certainly seems like you could take over someone else's domain name, and I suspect that public key cryptography is the only way to avoid this.

(edited to add: expired domains aren't the only attack surface here, domain takeover is also a thing, either by transferring the domain or simply changing the DNS records.)

I don't think you have to worry about that since user's data should be stored on the instance they registered on, which means that data should only be stored on those servers (I don't think that kind of data would be federated, correct me if I'm wrong).
So unless someone were to restart those servers with the same domain name and the data intact, it shouldn't happen.

I've only read the ActivityPub spec; I haven't read the Lemmy code.

With that in mind, my impression is —

The new domain owner — if they set up an ActivityPub server instance (e.g. a Lemmy) and got a list of the old user's post URLs — might be able to delete or edit the old user's posts stored on other instances. That is a vulnerability, albeit a small one.

If the old user was still listed as a moderator of communities hosted on other instances, the new domain owner might be able to take over that moderator role.

One way to fix this would be for instances to issue a public-key cryptographic identity to each user, and distribute users' public keys to other instances. Then activities purporting to be from that user would need to be signed by that user's private key.

Users' private keys would stay local to their home instance, so users don't have to do any key management themselves.

This would mean that if an instance goes away (and its key material is destroyed) then nobody can ever act as any of those users again. A new user created with the same username and domain would be a distinct user for all other instances too.

That is a vulnerability, albeit a small one.

"Small one" is very wrong here. This is by far the largest gaping security hole in the whole specification.

Since when is stealing a domain name easy? If it would be then google.com would redirect to another scam site every five minutes.

The only way you're going to steal a domain is if the owner stops paying for it.

If you steal gmail.com you could impersonate anyone with a gmail email address. How is that an argument?

Since when is stealing a domain name easy?

You either social engineer the needed data or hack the domain owner and change the Admin-C or Tech-C and then either directly or by request change the IP for that domain. You could also bribe some one working there or someone who works for the registrar or somehow gain access to the mail account of Admin-C or Tech-C.

https://www.hackingloops.com/domain-hijacking-how-to-hijack-domain-names/

You could also try to poison the instance’s DNS cache so the domain in question is resolved to an IP where the server is under your control.

https://en.wikipedia.org/wiki/DNS_hijacking

You could also register domain names that are either unpaid for whatever reason and thus marked as in transit and if the transit period is over you just claim the address.

https://en.wikipedia.org/wiki/Domain_drop_catching

And since you mentioned google.com:

https://money.cnn.com/2016/01/29/technology/google-domain-purchase/index.html

To recite @fubo@lemmy.world: Depending on DNS for security is generally a bad idea.

Sure, but if you lose your domain you already lost. That's it, game over.

I do agree it would make sense to issue every Lemmy instance and every user an asymmetric key pair they can sign against, just for extra security. But that might also break things because instances per domain are no longer unique. You can have lemmy.ml@publickey1 and then lemmy.ml@publickey2 and then lemmy.ml@publickey3 and so on. It would be an absolute mess.

This doesn't even have to be an attack. A new instance owner might decide to re-setup their instance and nuke everything or they simply lost the data. Or on a faulty Lemmy update things break and the private key gets regenerated or jumbled up. Especially right now in the early stages of this platform where things are bound to go wrong you don't want to accidentally nuke an entire instance.

What do you do then if a legitimate owner sets up the instance under the same domain again?

Besides that, if an instance really gets removed (which basically happens if someone takes over the domain, they don't have access to the instance data itself) other instances can simply defederate in an emergency. Though the only damage would be moderator accounts on other instances. The content is dead the moment the instance dies anyway (there just isn't a mechanism yet to clean it up if there is no delete events being sent, but that will probably come).