Immediate Action to Protect Internet Identity w/ Seed Phrases

I’m working on this problem in conjunction with @dostro and @Litzi from Internet Identity Labs. It is our opinion that the Internet Identity system has a major security vulnerability that should be addressed immediately. This was discussed at length in this thread, and assuming the facts stated are accurate, this attack may have been prevented with the fix we are proposing.

Currently all devices attached to an Internet Identity anchor have equal capability. If any one device is compromised, an attacker can remove all other devices and completely lock the legitimate owner out of their Internet Identity. There is no backstop that a user can rely on to prevent this.

We believe that the first iterative step to address this threat is to promote the seed phrase in capability and importance above other devices. To do this the seed phrase must be entered by the user before removing the seed phrase as a device.

We want to get community feedback and feedback from DFINITY engineers. If there seems to be general agreement, we will either encourage DFINITY to implement the changes themselves, or if necessary create a proposal with the code changes ourselves.

We hereby request comments.


I completely agree, there should also be different level of priviledge for seed phrases and devices.


You are so right @lastmjs, so right.


Strongly agree that II security needs to be improved, it’s actually the main reason I only login from a computer currently which I trust a lot more in terms of security compared to a smartphone or tablet. In rare cases I need to use my smartphone to login to some dApp i make sure to remove the mobile device from the list of approved devices as quickly as I can.

Having said that, I think a logical solution would be to have different permissions for devices allowing users to set specific devices with administrative rights to change list of approved devices or to add/remove seed phrases.


We agree there are possibly better yet more complicated solutions to the problem. We aren’t interested in discussing those here, we just want to do something quick and simple to address the threat immediately.

Because seed phrases are generally immutable on all other blockchains, and there is already a culture of those being the absolute final backstop to crypto security, it makes sense to choose that as the default elevated device for now. If you want to change it, you need to own it. We can come up with better rules later.


As the user coteclaude notes in the thread you linked, seed phrases stored in plain text are not a secure way though and can also be easily lost or corrupted especially by the average user as opposed to having selected admin devices limiting the surface of the attack vector.

1 Like

Couldn’t agree more with this proposal. Many thanks for reinitiating this conversation.


Typing your seed phrase in a computer connected to the internet is considered a bad practice.

I understand the issue and agree this need to be addressed, but I would not be comfortable having to type my seed phrase if I need to replace my device, which I’m pretty sure we all will have to do it sooner or later.

I would be more comfortable to use a hardware wallet, Yubikey or other form of two factor authentication.
Or have to confirm the action from a different device, so 2 devices would need to be compromised for the attack to work.


To be clear, this proposal is to type your seed phrase to authorize the removal of that same seed phrase.

Of course there are other improvements we’ll propose over time and your suggestion for a multi-factor confirmation is fantastic, but the one we’re proposing here removes an important attack vector that could be enforced as soon as next month (pending community approval and PR).


Totally. And we have been often told “what if I lose my seed etc”, but the seedphrase is generally immutable, just as you said, so waiting for a better solution, I don’t think it is crazy to proceed like we do usually : with an seedphrase to preciously keep safe in order to be able to mutate it (by entering it). I have always been in favor of this at least temporary solution. The problem is as old as the II, and I am glad you offer to solve this. I will strongly support it.


I agree that any added security is a good thing so I would most likely vote in favor if it gets pushed to NNS, still hope more will be done sooner than later.


This breaks one of the ways Origyn is using II at the moment. For technically unsavvy users origyn creates IIs for them and stores seed phrases securely(non-digital format). The users adds their device with help, but Origyn has a way to recover the account if necessary. Of course, they have to trust Origyn. When they feel ready to take full custody of their account they remove the Origyn seed phrase and create their own(but they do not have access to the old one…it is on paper in a safe location). This was mostly done for early investors and employees with little to no crypto experience. Origyn is in the process of unwinding this process and doesn’t plan to use it going forward, but it is a way the II can be used in its current incarnation. If this change is made, it should be a go-forward change.

1 Like

When I first read this comment I was thinking you were intending for the seed phrase to be entered to remove any configured device and the seed phrase. I see @dostro offered clarification that the focus is just on entering the old seed phrase in order to delete the old see phrase. This makes sense too. I think I also like the idea of entering the seed phrase to delete any device. Is that feasible or do you consider that to be scope beyond your proposal?

I do like this idea overall. I would be much more comfortable knowing that I have the ability to recover if someone gains access to any one of my devices.

Also, I just want to say how impressed I am with the idea that you all are pursuing this full stop including the possibility of creating a proposal that would implement code changes. This would be a major milestone for the IC to have someone in the community actually go through the full process of developing and implementing code changes via the NNS. I would love to see that happen…safely of course. I’m sure this would be done transparently in a way that enabled Dfinity to review before the proposal is submitted so they can vote No of they find a flaw in the code. I have no doubt that you three will be able to accomplish the goal safely, but it would be nice to know that Dfinity would have the ability to cast votes to reject if they feel it is needed. It would be pretty exciting to see this implemented as a community developed change.


As described before (but I cannot find it right now), I think the right way to build this feature is by allowing two levels of security for public keys: “more secure” public keys can add/remove any public key; “less secure” public keys cannot add/remove “more secure” public keys. That is a strict generalization of the functionality proposed here, but it also allows other setups – such as a redundant setup with two “more secure” devices.

Beyond that, it’s merely a matter of prioritization.

EDIT: In our day-to-day support, we have repeatedly dealt with cases where users simply forgot or lost their seed phrase. So this should be an optional feature that can be activated on anchors, not a general feature of recovery phrases in Internet Identity.


@skilesare @bjoern I think it’s reasonable to make this an opt-in feature and the default moving forward.


I think this is beyond the scope of the proposal. My gut reaction would be to avoid that, since you really should never be entering a seed phrase into a device connected to the internet.

But again there are many ways to improve the situation, but we want to get the minimum viable fix out soon, this vulnerability has been haunting me for too long.


Good point on making it opt-in, perhaps something like this?

Opt-in checkbox upon seedphrase generation

No change to Anchor Management screen

Instead of simply allowing user to delete their seedphrase and if user opted-in to seedphrase re-entry prior to deletion, force re-entry


I think it’s important that you can opt-in to the seed phrase confirmation for removal on an already-created seed phrase.


Makes sense, we could do something like adding an icon to the recovery phrase row and on click, display a similar modal to the one for “Remove Seedphrase” that describes what this would do.


Bjoern’s comments on this from a previous thread: