Account switching

[ekzyis]

Is your feature request related to a problem? Please describe.

It would be nice if we make it very easy to switch between different accounts.

• stackers could easier maintain multiple nyms
• companies can easier maintain individual and an official account (like our official stacker news account)

Additionally, it would be nice if we could easily switch to anon without having to log out. But we don't want a real session as anon for privacy reasons (wallet history including invoices would be visible).

Describe the solution you'd like

Add a "switch account" option to the user dropdown which then opens up a modal to pick or add another account:

After clicking on an account, we swap the existing JWT with the one for that account which should be all that is needed to impersonate a different account.

If you want to add another account, you need to verify ownership of that account first (using any authentication method of that account).

If you want to switch to anon, you just click on it and then it looks like you are logged out but clicking on login would show you all available accounts. Clicking on any of these would instantly log you in without new authentication (since we already have the required JWT stored).

[huumn]

I looked into this a bit out of curiosity. Twitter stores the other auth tokens in a separate cookie key:

twid=<user_id0>
auth_token=<relatively static auth token corresponding to user_id0>
multi_auth=<user_id1>:<auth_token1>|<user_id2>:<auth_token2>...

[ekzyis]

Mhh, so they don't care about the privacy aspect of this solution: they can know which accounts are linked.

I think a solution where we don't know any links between accounts would definitely be nice.

But not sure on how relevant this is since in theory, if we want, we could use the IP address to link accounts.

So maybe we could use the same solution as twitter since there is not significantly more trust required with the one-to-many cookie solution compared to just looking at IP addresses.

(I am ignoring networks like Tor or I2P here which don't leak IP addresses.)

[huumn]

I think from a security perspective it's the only thing that makes sense afaik

[ekzyis]

A nice unintended side effect of this could be that it's easier to turn off personalized feeds

[hellmanhellman]

Isn't it important that you know if accounts are linked? IP isn't necessary, but of course a great part of the fingerprint, which also includes literally every aspect of the user's vocabulary, typing speed, user agent, etc. Just treat the fingerprint like a password and encrypt it clientside. Locality-sensitive hashing can keep the clients unknowable to your records, except for the fact that similar fingerprints will have similar hashes.
You don't want a botnet bought by Michael Saylor raining down on you screaming Buy tulips! Do you?

[ekzyis]

Isn't it important that you know if accounts are linked? IP isn't necessary, but of course a great part of the fingerprint, which also includes literally every aspect of the user's vocabulary, typing speed, user agent, etc. Just treat the fingerprint like a password and encrypt it clientside. Locality-sensitive hashing can keep the clients unknowable to your records, except for the fact that similar fingerprints will have similar hashes. You don't want a botnet bought by Michael Saylor raining down on you screaming Buy tulips! Do you?

Not sure I understand what you want to say. Did you want to say "Isn't it important that you don't know if accounts are linked?"? Then it would make more sense.

Just treat the fingerprint like a password and encrypt it clientside

Encrypt what clientside using the fingerprint as the "secret" key? The JWTs of the individual accounts? How would encryption even be possible on the client for JWTs inside HttpOnly cookies? And why even encryption? To keep them safe while switching them in and out to not link accounts? Imo, this sounds like achieving some (probably insignificant) privacy by risking severe security vulns like account takeovers via XSS or whatnot.

Also, treating fingerprints like passwords sounds a lot like "roll your own crypto". Never roll your own crypto.

You don't want a botnet bought by Michael Saylor raining down on you screaming Buy tulips! Do you?

I don't understand how this is related to anything before it.

---

Also, need to backpedal on this:

Mhh, so they don't care about the privacy aspect of this solution: they can know which accounts are linked.

Maybe they tried to care about the privacy but encountered the same trade-off between security and privacy and decided to go for the more secure solution. Like we'll do now, lol

[hellmanhellman]

I've yet to be convinced that I'm helping professionals here, and your link to "Roll your own crypto" helps little. It seems to me that the end goals of your organization misalign with my own, on a larger scale. Wish you the best out there.

[ekzyis]

I've yet to be convinced that I'm helping professionals here, and your link to "Roll your own crypto" helps little. It seems to me that the end goals of your organization misalign with my own, on a larger scale. Wish you the best out there.

DM'ed you on SimpleX since I am confused by this answer. We're trying to understand what you're saying and engage with your comments but

I've yet to be convinced that I'm helping professionals here

is not a respectful way to respond. You didn't even respond to any questions I had.

Just FYI, you obviously don't have to engage with us.

[ekzyis]

UX question:

If we login into account X, and want to add account Y, we need to authenticate for account Y. This means a login flow within the existing session for X is started. After successful authentication, an additional session cookie for that account is set. Assuming we can now switch out the session cookie the server will use for user actions on the client (thinking about using a cookie which is a pointer to the session cookie we want to use and modifying this "pointer cookie" via JS), this should work fine.

However, the moment we log out, all session cookies are destroyed.

So if we login into account X again, all accounts are lost and we need to add all accounts again.

I think this is bad UX. The accounts should at least show up but we need to authenticate again that we own them.

But this means we need to persist the links in the database, too. So we can show the user which accounts they did link in the past.

But at this point, we could also implement that if you login into X, session cookies for all linked accounts are set. So no need for authenticating that we own Y ever again. But not sure if that's good.

edit: lol, forgot the question. UX question: make "account switching" updates persistent across sessions?

I'd say yes, but with new authentication required.

edit 2: maybe this is more something for the next iteration on this feature to keep the first iteration as simple as possible.

[huumn]

Yeah KISS it. fwiw twitter doesn't remember which accounts I've auth'd before