Nomadic identities


#1

I’ve been thinking about the problem of moving my account from my instance to another instance or platform. A few days ago I asked about it and received this answer.

Basically the options proposed are:

  1. To use the DID scheme
  2. Follow what hubzilla does

What are your opinions on this? Since is something that will determine the way of creating users for activityPub is an important issue to discuss at the beggining


#2

Is that question specific to Anfora or a general ActivityPub one? :slight_smile:


#3

I wanted to talk about it for all the project here since is something that may be important. But maybe I should move it to the anfora’s sub


#4

I think that’s important in general, not just Anfora :slight_smile: I’m afraid i don’t have any valuable input on this yet as i’m pretty new to this whole activitypub stuff. I’ve heard about like 0.5y ago and instantly felt in love with the idea but some more time need to pass till i’ll be more confident in that topic.

Anyway, that’s something i will definitely keep in my head!


#5

Pixelfed is investigating Nomadic Identities in this github issue: https://github.com/pixelfed/pixelfed/issues/216


#6

Thanks! That answer is very complete. It’s true that we have a big problem here but I’m with this partial solution of let all ready for when it’s the moment


#7

We made a workshop last July about this, and our conclusions where that Nomadic identities are a complex subject.

Basically, we found out they solve two problems:

  1. Don’t be affected by the downtime of your instance (since your identity is replicated elsewhere)
  2. Make it easier for other people to find you (since you can use a single identity)

Maybe those two problems can be solved separately and independantely, without the additional complexity. For #1, we could work on a standard to export/import account data, making migration easier, and mitigate the issues caused by your server downtime (e.g. by providing a fallback account on the Actor entity, so your followers know where to reach you)

#2 is probably solved already by things like rel=me (http://microformats.org/wiki/rel-me)

I know this is a bit off based on your initial topic, but I thought you may want to hear this opinion. For me, nomadic identities are a bit like blockchains: complex systems with serious limitations (if you loose your wallet, you loose your money, I feel like the same thing may happen for nomadic identities).

Edit: I realize I forgot one use case for nomadic identities, which is reducing the number of managed identities and use the same identity to sign in on various apps.


#8

On the contrary, it’s the exact opposite :slight_smile: with the ability to clone your identity to multiple servers, you are less likely to lose your account!

Currently in AP systems, if your domain goes down, your account goes down with it. The only work being done to counteract this is the potential development of a alsoKnownAs property that can optionally be attached to Actors, but this does not handle any replication logic; it’s not really any different than rel=“me” in microformats. (related: https://github.com/w3c/activitypub/issues/300 on w3c/activitypub issue tracker)

The above (what you refer to as #2) is not really “using a single identity” as much as it “signaling that these separate identities represent the same person”. It also fails in cases where the AP software does not check for / store cyclical references, cases where the user does not explicitly establish such a reference, or cases where the user neglects to do so until the server goes down (hence not solving #1).

Fundamentally, an identity consists of a guid and a private key (and optionally an address book of locations, to notify your contacts that they should update their references to your new location). The private key allows you to establish your identity, and losing it is the same as losing your accounts; fortunately, most current AP servers are generally responsible for keeping your private keys safe, so the user does not have to do any key management of their own. The guid exists so that a potentially insecure keypair can be revoked and cycled out for a new one, if necessary (with confirmation by all your contacts).


#9

What I meant by that is that you have replication, yes, but your whole identity is tied to this private key you’re mentionning. If it’s compromised or lost, your identity is gone (as it would be if you loose your *coin wallet). People forget their passwords, loose stuff, that’s just being human. Also, databases are compromised all the time.

What can you do if someone has access to your private key and uses it to do bad actions in your name? On typical services you would change your password or contact the support team to block your account until you can prove that you are the actual owner. How does it work if the identity is decentralized in the way you’re suggesting?


#10

I missed that part: how does that process does work in practice?


#11

All contacts would have to approve a key-change, not much differently than what might already happen if, for example, your server got hacked and an attacker stole your private key. But having access to the private key is actually a higher-level breach, and an attacker does not need to do as much. Right now, all it takes to compromise an account is the email and password, and that would not change. Having access to the account means you could authorize as that user, wherever possible. This is why passwords cannot be your only method of authentication. It also means that worrying about losing a private key would mean that you are in more trouble than simply losing your password.

Nomadic identity cannot solve the issue of security – that is still the responsibility of the software implementation. But what can be done to prevent false migrations? Probably some sort of verification between the two instances – “do you want to migrate/clone your account to this server?”, which, if the primary instance is still online, then the user can simply reject that request.

  • If a hacker somehow obtains only the private key but not the password (doubtful, since they need server access), then they would be unable to initiate a restore-from-backup until an authoritative message arrived from the user’s current instances.

  • In the extremely unlikely case where all of a user’s instances are offline, AND a hacker manages to obtain a backup of the private key from somewhere, then sure, the account would be lost, as that would be analogous to losing the keys to your house and having someone change the locks while you’re gone. But note that this is no different from the “losing a password” case that exists today.

  • In the slightly-more-likely case where all of a user’s instances are offline, and a hacker obtains a backup of the user’s posts and guid and contact book, and decides to generate a new keypair, the user’s contacts will have to approve the key-change request, since this will technically be a new identity.

And so on. In summary, I don’t believe that the “lose a private key” case is meaningfully different from the “lose a password” case, but it can provide both more security (by offering more robustness) and also more risk (because you have to trust another admin – but this second admin can be yourself, if you wish!)


#12

Thank you for the detailed explanation @trwnh, I have a much clearer vision now! If you don’t mind, I still have a couple more questions:

  • Can the key rotation be initiated from any server replicating your identity?
  • How can you change your password if it’s compromised (or for any other reason)? AFAIU from your explanations, it’s binded to the private key, but I may be wrong?
  • Can you trigger a password reset from any server replicating your identity?

I agree with that, however, the identity moder has a direct implication on the security (and threat) model of the applications, and it seems important to me to understand the trade-offs of a given method.


#13

I’m more familiar with the theoretical rather than the implementation details, but in theory, key rotation can be initiated from any device with the private key, so yes, any server hosting your identity can initiate a key rotation. I think in practice, the way Hubzilla and zot do this is by designating one of the servers as the “primary” and all the others as “secondary”. The primary zot server handles all logic and replicates your information to all your secondaries, but if the primary server goes offline (perhaps permanently), then any already-authorized secondary server can claim to be the new primary server following a user-initiated update process. Once you have a primary server online, you can take any account-related actions. I would defer to the zot documentation for more details on the technical side of things: https://project.hubzilla.org/help/en/developer/zot_protocol

If your password is compromised, then you lose access to just that account on that server. I don’t think there’s anything stopping you from having a different password on each server; think of the server as simply an entry point into the zot network. I can be @a on social.trwnh.com identified by somepass, and @trwnh on example.social identified by someotherpass… i could make trwnh.com the primary server and example.social the secondary server, post from either server, and if i ever come to distrust example.social, then I would disconnect the two accounts and perhaps cycle out my keys (and warn my friends for the reason I’m cycling my key out, so that they know that I still have access to the account). If my primary at trwnh.com was hacked, then I would contact the admin (myself) to lock the account and change my password there. Of course, I’m limited in what I can do with regards to regaining access, in a similar way that I might be limited on any system existing today if I lost my password.

In more general security terms: hosting your identity on multiple servers increases the potential attack surface without introducing any significantly different attack vectors. And you can still choose to host your identity only on one server, even in a nomadic system. But the main advantage you gain is that your identity is now no longer bound to DNS. Although, DNS can still be used as a superficial trust signal, because maybe you trust that I have control of trwnh.com and that I would not sabotage my own account by pointing it at some primary like untrustworthy.social. On a user level, this means you can change username and domain quite easily, rather than being stuck with what you sign up with; it’s much the same as moving to a different house and updating your physical address. Just because I once lived at 123 Example St. doesn’t mean that no one else can live there after I move out.


#14

This is really thorough @trwnh, thank you! :ok_hand:

I realize most of my reservations came from this password-reset / account compromise thingy. Based on what you posted, the way this is handled in Zot (and possibly other protocols) is much saner and powerful than what I thought.