Asklemmy @lemmy.ml maggoats @lemmy.world 1y ago

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

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

If they make their own [email protected], how do federated instances distinguish who's who?

Have I misunderstood the role of domain names in this?

28 comments

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.
  
  But does ActivityPub actually have public keys? That would need to be in the protocol I think.
  
  Oh that's interesting. Now I'd really like to try that out :))
  
  Maybe it would be enough for instances to have their keys and to be securely identifiable, and not all user accounts?
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.)
Ohh interesting. I don't know, although I think that'd be rare because most people use big instances. Although maybe if a big instance goes down someone could reuse their domain name and remake all those accounts?

28 comments