Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Identity recover #3466

Closed
strk opened this issue May 15, 2017 · 28 comments

Comments

@strk
Copy link

commented May 15, 2017

I've learn that loosing the private key of your identity makes it impossible to recover. If this is confirmed we need a way to allow recovery.

@fabrixxm

This comment has been minimized.

Copy link
Collaborator

commented May 15, 2017

  • Go to /uexport (Settings -> Export personal data).
  • Select "Export account".
  • Save the file somewere.
    time passes, your server explode, you reinstall it but you don't have backups
  • Go to /uimport (Register -> Import account)
@strk

This comment has been minimized.

Copy link
Author

commented May 15, 2017

@MrPetovan

This comment has been minimized.

Copy link
Collaborator

commented May 15, 2017

If you don't have the private key then there's no way of recovering your account someone else couldn't use to impersonate you. That's the whole point of public-private key pairs.

@fabrixxm is right about the only way of preventing such issue in the first place: backing up your private key so that you always have it.

So we can't add a way of recovering your account (because there's no trusted third party), however we can make it obvious or mandatory to backup the user account once created.

@MrPetovan MrPetovan added Docs UX labels May 15, 2017

@strk

This comment has been minimized.

Copy link
Author

commented Jun 4, 2017

@hypolite I hardly disagree about leaving the choice to the software and not to the user. You have to decide if you want to trust the new user key or not. It is up to you to find an offline channel if needed.

Do you trust my profile URL to be under my control ?

We used to be "friends", don't you find it absurd that your software gets to decide we cannot be anymore now ?

@annando

This comment has been minimized.

Copy link
Collaborator

commented Jun 4, 2017

If you find an offline channel where you can verify the other person then both people can decide to remove the contact on their side and to join again.

Of course this is much work when you have got much contacts, but this "I accept the changed key" is something that many people will do without any thought - just because they don't understand the background.

@MrPetovan

This comment has been minimized.

Copy link
Collaborator

commented Jun 4, 2017

We used to be "friends", don't you find it absurd that your software gets to decide we cannot be anymore now ?

It never was about that. Of course you know you're yourself, but only through Friendica your friends have no way to be sure, and public-private keys are a way to ensure that you always are yourself. You losing your private key is functionally indistinguishable from someone forging a message on your behalf from the software perspective.

@strk

This comment has been minimized.

Copy link
Author

commented Jun 4, 2017

@Hypolite initial connection is made w/out any user confirming any public key fingerprint, so the user is really always just trusting the DNS system and the supposed owner of the Friendica node hosting the target friend user.

If this kind of trust is ok on the first connection, why shoudn't it be ok later ?

I think the security aspect of Friendica is being pushed beyond reasonable boundaries, especially as it gives a false sense of security. Example: plain text mail notifications containing full body of otherwise military-grade-encrypted private messages.

I don't think Friendica is a tool that can be trusted as per privacy of shared messages, and breaking usability in the name of such false security is just bad for the project (IMHO).

@annando: the problem of users taking decisions w/out thinking about them is a non-problem. ask them to think more, give them all information about what each choice implies. instruct them. don't threat your users as sheeps...

@MrPetovan

This comment has been minimized.

Copy link
Collaborator

commented Jun 4, 2017

Initial impersonation is of course always an issue, but there's nothing created public-private key pairs can do about it. However, such key pairs are required to communicate with Diaspora for example, so it's not just about Friendica's security. Even if you could recreate a private key in Friendica, Diaspora contacts wouldn't be able to communicate with you anymore because we have no control over their end.

And I believe trusting users with backuping their data in case of a crash precisely is not treating them like sheeps.

@strk

This comment has been minimized.

Copy link
Author

commented Jun 4, 2017

This tracker is for Friendica.
Diaspora should get its own ticket (I wont' open it because I don't use Diaspora).

@Hypolite I think not giving users a choice to avoid them taking the wrong decision is threating them like sheeps.

@annando

This comment has been minimized.

Copy link
Collaborator

commented Jun 4, 2017

Like we discussed on IRC, there would be some possible way. I guess we can detect a connection request and notify the user. We could print a notification like

You recently had a contact request from user@domain.tld who is already your contact. Maybe someone tries to trick you - or the user had accidentally deleted your contact or had reinstalled Friendica. If you think this contact request was okay, then delete the contact and try to connect to the contact again.

@strk

This comment has been minimized.

Copy link
Author

commented Jun 24, 2017

I like the suggestion, except I'd take a step further and let the user click a button to refresh the connection (rather than requiring manual removal and re-addition of the connection).

@strk

This comment has been minimized.

Copy link
Author

commented Jul 1, 2017

I was thinking, there should be code to handle "identity migration", right ? Could this kind of recovery use that same code ?

@annando

This comment has been minimized.

Copy link
Collaborator

commented Jul 1, 2017

The identity migration works with importing the backup file that users are supposed to do when creating an account :-)

@strk

This comment has been minimized.

Copy link
Author

commented Jul 1, 2017

uhm. But it still works with a different domain ?

@annando

This comment has been minimized.

Copy link
Collaborator

commented Jul 1, 2017

Yeah, because we keep the key.

@strk

This comment has been minimized.

Copy link
Author

commented Jul 2, 2017

@strk

This comment has been minimized.

Copy link
Author

commented Jul 3, 2017

This is not a Docs/UX issue, btw

@tobiasd tobiasd removed the Docs label Jul 3, 2017

@strk

This comment has been minimized.

Copy link
Author

commented Aug 6, 2017

@annando had you found any time to move steps in the direction you envisioned ?

@annando

This comment has been minimized.

Copy link
Collaborator

commented Aug 6, 2017

No. Maybe at the Hackathon somewhere at the end of the year we will find some time to discuss about this.

@MrPetovan

This comment has been minimized.

Copy link
Collaborator

commented Feb 22, 2018

@annando Do you have an estimated timeline for this feature?

@annando

This comment has been minimized.

Copy link
Collaborator

commented Feb 22, 2018

Not until now.

@MrPetovan

This comment has been minimized.

Copy link
Collaborator

commented Feb 22, 2018

This would mean you do have a timeline for this feature now. Maybe you were trying to say "None so far"? I feel this issue is important as it is preventing an known instance from being spun up again.

@annando

This comment has been minimized.

Copy link
Collaborator

commented Feb 22, 2018

I mostly don't have timelines for any feature. I know that I really have to complete the whole item handling at first. Then I can have a look at possibly using the Diaspora transport layer to transport Friendica payload. This would fix several things. Next could be AP.

Problem with this issue here is that it really only touches the case in the Friendica <-> Friendica communication. The communication with Diaspora users will stay blocked for eternity. We cannot change their key storage method. Because of this it would be much easier to use a different hostname and/or username.

@strk

This comment has been minimized.

Copy link
Author

commented Feb 22, 2018

@MrPetovan MrPetovan added this to the 3.6.1 milestone Mar 12, 2018

@strk

This comment has been minimized.

Copy link
Author

commented Mar 27, 2018

Someone on Diaspora pointed me to previous design about identity recover from 2016:
https://the-federation.info/specs/backup-restore/
he mentioned Diaspora devs were not welcoming to such a spec so he left:
https://wk3.org/posts/4663259#36e70de9-5017-4713-8bea-4b3b5e9dc0b6

Maybe we can do better :)

@strk

This comment has been minimized.

Copy link
Author

commented Mar 27, 2018

Sorry for the noise, a quick look at that specification tells me it's not the same kind of "identity recover" I'm after. That one is for the case in which you want to change your domain, in my case I'm still in control of my domain but only lost the keypair..

@tobiasd tobiasd modified the milestones: 2018.05, 2018.08 May 6, 2018

@tobiasd tobiasd modified the milestones: 2018.08, 2018.11 Jul 30, 2018

@tobiasd

This comment has been minimized.

Copy link
Collaborator

commented Nov 17, 2018

We have discussed the issue on the 2018 Hackathon in Berlin. This cannot be fixed in a clean way, as well when switching to the AP protocol. Hence I'll close the issue.

@tobiasd tobiasd closed this Nov 17, 2018

@tobiasd tobiasd added the Cant Fix label Nov 17, 2018

@strk

This comment has been minimized.

Copy link
Author

commented Jun 14, 2019

Closing this issue is a big mistake. You're missing the point, and it's a pretty big point really.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.