I field quite a few questions about all things Internet Computer. A few times I have run into a scenario when a user’s Internet Identity becomes corrupted (or seems to be). They only have 1 device and 1 recovery phrase. The device stops working all of a sudden. Haven’t pinned down exactly what causes it. But in this situation they can’t login as usual on the device.
So the natural next step is to recover the account with the recovery phrase. So they click recover account, put in their anchor, but then get an error saying the anchor is not recognized. This is even though they have a recovery phrase for that Internet Identity.
Is it possible for an Internet Identity to be corrupted? Or somehow get removed and impossible to be recovered with seed phrase?
I’ve seen this multiple times across a few different people and figured a discussion here might be best. Thoughts?
I think that it is best to have a discussion here. I have also observed, anecdotally, about the broad outlines of what you have discussed through some other posts in forum.
I have two internet identity created prior to ledger integration through which I have created a total of 5 neurons, 8 years , non dissolving. For full disclosure, I am really afraid of using Internet Identity because of the discussion here(Internet Identity Lack Of Security) to manage my neurons. I have created an entire system here (GitHub - icdev2dev/sachvo: Manage iND neurons without Internet Identity) to avoid logging into Internet Identity for the purposes of merging maturity and spawning maturity.
The situation that we are discussing in this topic has to do with Internet Identity corruption. Both of my Internet Identities have NOT been corrupted. The only detailed forensic that was conducted, that I am aware about, for the potential of internet identity corruption was here.(My NNS has been stolen,Please help me). There was shown that , IN THAT CASE, the internet identity was not corrupted.
Others who have negative experience first hand might want to chime in as well.
I’d suggest a simple first step when dealing with “sudden” problems: check the system’s time. There are a lot of APIs that depend on accurate time keeping, and a lot of users that seem to have their clocks change “suddenly” (for whatever reasons). There are a lot of people asking about this on Discord, and tbf to them, some of the error messages are not exactly straight forward.
I would suggest you first ask them to check their systems, sync the clocks, and try again.
This is a really good response. Although usually you can inspect and get an ingress time error that points it to being more of a time error right? (maybe not in all cases though)
In any case, this is a great step that I usually don’t tackle in my debugging.
I think the initial question can be understood in two different ways:
Incorrect recovery phrases: It seems unlikely that a recovery phrase would just “stop working” short of being replaced/deleted either accidentally or as part of an attack. That said, for some weeks last summer, the flow that II used to create those recovery phrases was suboptimal: the phrase was generated and displayed on the user’s screen before the corresponding public key was stored in the canister. That left some people with non-functional recovery phrases, because they never advanced far enough in the creation flow to have the canister store the relevant information. (We changed the flow since then, now we first store the public key and then show the recovery phrase on screen.)
Deletion of recovery phrases by accident or as part of an attack: That is an issue, as witnessed by the case quoted by @Icdev2dev. The reason, as discussed in the quoted thread, is that all “devices” associated with a user’s II are equal, so any other device (in that case a Yubikey) could be used to delete and ultimately replace the recovery phrase.
Our current thinking is that we should enable II to support two levels of authentication mechanisms where the “less trusted” mechanisms cannot add/delete “more trusted” mechanisms – but it is the individual user’s choice which mechanisms are marked as “more” and “less” trusted. That way, each user can make their choice according to their own workflow and preference, and in it is still possible to replace “more trusted” mechanisms by specifying multiple ones.