Recovering identities from pod disaster

Federation
1

When a pod loses its users’ private keys, their identities become unusable. Forever.
The only thing a user can do is to create a new identity, because there is no way to ever reuse the old one.

This is an usability problem that has prevented me from having anything to do with diaspora, for two reasons:

  • Some users (me in particular) really care about that relatively meaningless string called the identity (in the form of user@pod), their login, their email address, etc.
  • Making a resource unusable forever is not going to be healthy for the network as a whole. This breaks the network a little, and it will not ever recover from that breakage. Bad things happen, and as diaspora grows, they will happen more.

No other protocol I can think of suffers from this problem. Centralized protocols simply provide a way to reset a password. Decentralized protocols either don’t sign messages (like email), don’t bind resources to keys (like email with pgp, because you can have multiple keys for one email address), or provide a way to inform that the user’s key has changed, and re-validate it (like signal).

Diaspora tries to ensure that users (or their pods) are in control of their activity, to the point that without their keys, they can’t even delete their accounts, as it might be considered censorship (and in some cases it certainly is).

However, by design, it also binds the identity to a key, and does not allow to rebind it to another one in case of a disaster.

I’d like to discuss the possibility of creating a method of reusing identities, that can be considered secure enough for users. Of course, any method allowing to bind another key to an identity will be strictly less secure than not doing that, but security is not the only thing important in diaspora. Usability is one of the others.

My initial idea is to trust the domain controlling the pod. Right now, someone controlling the domain can impersonate the pod however they want, and the only thing they cannot do is impersonate the users. They can, however, create new users, thereby wasting resources of the pod forever.

It can be argued that in some cases, it would be easier for an attacker to gain control of the domain than of the server a pod is running on, and it’s a valid argument. We could, however, check the pod’s SSL certificate. That way, if the podmin would like to secure themselves from an attack on their domain, they could utilize HTTP Key pinning to instruct other pods not to trust other SSL certificates.
Other podmins, who prioritize disaster recovery over that particular security mechanism, might simply not publish HPKP headers.

I think that this solution’s usability benefits outweigh the security drawback of allowing key replacement at all.

To summarize, the only thing that I’d like to be possible in diaspora is reusability of identities in case of pod disaster. So I’d like to discuss how that can be done, and if there’s will to do it at all.

Note: This discussion was imported from Loomio. Click here to view the original discussion.

2

I would suggest another way: Friendica - for example - keeps the key forever but you can move to another server. I think the safest method is that users can export their keys. And when a server would loose all its data, the users simply could create new users and could add their keys there.

This seems to be a more safe method and additionally it provides a good way for moving to another server.

3

However, this still leaves a possibility that an user cannot recover his identity.
I don’t think we can expect every user to export their key and keep a safe backup of it.

Not to mention that in case of most users this would actually lower security of the key, since most people are incapable (or unwilling) to store anything securely.

Anyway, this would place too much burden on users, in my opinion. And would not really solve the original problem of recovering the identity without a key.

4

I don’t know how diaspora works. but i know some other software that have this lockout problem.
ie, freenet, and blockchain. that relies on asymmetric keys being lost.

one thing that could be done is that the user could generate the keys locally (the browser can do that afaik) and send only the public key to the server, and backup the private key.
this would be very cumbersome but could a allow a user to reuse an identity without having to concede that identity to any party.

it could even allow to keep using an identity on a different pod.

5

That would still not solve the problem of reusing identities, would be too cumbersome, and would introduce an additional security consideration, namely that even if the user computes and stores the private key himself, he would still need to trust the pod’s javascript code not to upload it anywhere (or use it maliciously in another way). Which, in case of a XSS attack, would introduce a worse security problem than just storing it on the servers.

As to what blockchains do: in bitcoin, your key is more or less your identity, there’s no human-readable string to re-use. In namecoin, your names are valid for about 200 days, so that if you lost your key, you could regain control of those after some time. Note that we’re not talking about a way to recover your data if you lose your key. Just the identity.