Social account recovery can work more-or-less reliably, if peers contact the user in some means _other_ than Nostr, to verify that the identity of the user. I think the protocol should enforce this someohow, otherwise the sceme is easy to trick (peers will just press on the green button wanting to help, without real check).
The flow I imagine:
- User realizes that he lost his key, or someone else is posting shit in his name (key compromise), or potential key compromise (not yet misused)
- User initializes Emergency Recovery in a supporting client. A new identity is created.
- User identifies a few trusted nostr user peers who can verify his identity and have other real-life non-nostr means of contacting the user
- Posts a event about the key rotation, with the list of the peers, and a min. threshold.
- Tagged peers should:
- contact the user through some non-nostr means, make sure it is indeed the real person
- generate a unique secret code (details tbd, e.g. by signing the event ID of the rotation event)
- if not in doubt about the user, send the secret code to him through non-nostr channel
- The user, once collecting enough 'ack' codes, posts an event closing the key rotation.
Any client can verify the integrity: that it is posted by the same account, and that each ack indeed comes from the mentioned peer (verify cryptographically), and the number is sufficient.
A malicious attacker can misuse a scheme to steal an account, if he can convience a few users that he is the impersonated user. To alleviate this, the real user can launch a similar counter recovery process, which takes over provided that it is backed by _more_ peers. This way the real user can win as long as more peers attest this.
This scheme is basically what fiatjaf has described in NIP37, with the enhancment to capture the proof that peers have contacted the user. What do you think fiatjaf (npub180c…h6w6) ?
optout
npub1kx…3lecx
2023-10-16 06:45:13
in reply to nevent1q…ms5w
Author Public Key
npub1kxgpwh80gp79j0chc925srk6rghw0akggduwau8fwdflslh9jvqqd3lecxPublished at
2023-10-16 06:45:13Event JSON
{
"id": "cb6d885cf27bc8b96828026980379c924774506c642110e39bc67b0c30696070",
"pubkey": "b190175cef407c593f17c155480eda1a2ee7f6c84378eef0e97353f87ee59300",
"created_at": 1697431513,
"kind": 1,
"tags": [
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
"",
"mention"
],
[
"e",
"f7b54bbf59de28146e3bba0321abb53810312f27cf82b5c7dabc49a74c576dd7",
"",
"reply"
],
[
"p",
"fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"
]
],
"content": "Social account recovery can work more-or-less reliably, if peers contact the user in some means _other_ than Nostr, to verify that the identity of the user. I think the protocol should enforce this someohow, otherwise the sceme is easy to trick (peers will just press on the green button wanting to help, without real check).\n\nThe flow I imagine:\n- User realizes that he lost his key, or someone else is posting shit in his name (key compromise), or potential key compromise (not yet misused)\n- User initializes Emergency Recovery in a supporting client. A new identity is created.\n- User identifies a few trusted nostr user peers who can verify his identity and have other real-life non-nostr means of contacting the user\n- Posts a event about the key rotation, with the list of the peers, and a min. threshold.\n- Tagged peers should:\n - contact the user through some non-nostr means, make sure it is indeed the real person\n - generate a unique secret code (details tbd, e.g. by signing the event ID of the rotation event)\n - if not in doubt about the user, send the secret code to him through non-nostr channel\n- The user, once collecting enough 'ack' codes, posts an event closing the key rotation.\n\nAny client can verify the integrity: that it is posted by the same account, and that each ack indeed comes from the mentioned peer (verify cryptographically), and the number is sufficient.\n\nA malicious attacker can misuse a scheme to steal an account, if he can convience a few users that he is the impersonated user. To alleviate this, the real user can launch a similar counter recovery process, which takes over provided that it is backed by _more_ peers. This way the real user can win as long as more peers attest this.\n\nThis scheme is basically what fiatjaf has described in NIP37, with the enhancment to capture the proof that peers have contacted the user. What do you think nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 ?",
"sig": "10338539dc7a4eca4e6517f78f6ad7d64fcb3ae95dcb8c6555f377d78a5e8aa3ffc2f8040bafd2473fc22f7d7c5a15504a1cb6b6687b2f42568583629c861c5b"
}