Internet Identity Lack Of Security

I think the security problem of Internet Identity solution should be placed in top priority. It can’t be delayed anymore. Otherwise a lot of people won’t take the risk of using their Internet Identity with other authentication devices than yubikey or ledger FIDO(U2F) on desktop, won’t have patience to create another Internet Identity without neuron and ICP staked for using it with other devices more practical to use dapp with fluidity and won’t have patience to connect their yubikey or ledger just to use a social dapp, what it is eventually very bad for massive adoption, cause having to connect one’s yubikey to Desktop before interacting with Facebook would be a non sense. For example, I can’t use any app on my iPhone, because I don’t want to risk hacking of my internet identity and lose my staked neuron, so I would like to often connect to distrikt etc, but I rarely do, because it is a lot of steps to do this…

Everybody should claim the Internet Identity seedphrase can’t be removable or changeable without having to enter the seedphrase in the first place. This risk of seeing one’s Internet identity and its associated staked neuron lost forever is insufferable. None whale wants to take such a risk ! It has to be corrected ASAP. I already talked about this several times, but no one among @Dfinity or Dev seems preoccupied by this eminent lack of security whereas users are ! Without this, again, no massive adoption.

If we had to enter the seedphrase before removing it, we could still be hacked and have our Internet Identity and then our neuron stolen for a while, but not forever ! So if our ICP are staked, we even don’t lose anything, cause we just have to enter our seedphrase and suppress the device that the attacker would have installed since the stealing. But if the attacker can removes our seedphrase, because he is not asked our seedphrase before being able of removing it, and after this just has to create a new one, our neuron and more globally our Internet Identity is lost forever !

People with big amount of ICP are terrified about being stolen like this forever, so add the non removability of seedphrase without before entering the seedphrase, like google, apple and any companies do for account. It is a non sens that we can suppress a seedphrase so easily and create a new one just after, it is a nightmare for anyone, overall for big investors who consequently remains investors, but non users, cause too much scared for taking the risk of connect app with a phone.

But even without speaking about investment, as long as people won’t be able to be reassured about the possibility of taking control of their Identity back, because their seedphrase is not removable as easily, a lots of people won’t take the risk to develop a full identity who can be stolen in one second forever.

So people, let’s talk about this, and make the seedphrase non removable without having to enter it in the first place to defend the big amount of icp staked and to allow people to take control back sooner or later.



First of all, the alternative is , of course, NOT to stake a large amount of ICP through the NNS dapp; which relies on internet identity. You can use quill, keysmith etc without internet identity to stake.

However, for most mere mortals, making the internet identity as secure as possible SHOULD BE one of the topmost priorities.

Currently the seedphrase can be changed by anyone who has access to any authentication mechanism with internet identity anchor ( including windows hello etc). I believe that we should make the seedphrase the “final” authentication agency for the internet identity.

In that context, a seed phrase that only be changed by it’s own consent will solve a lot of nagging issues for the end user.


@wpb @Arthur @hpeebles @Kyle_Langham @lastmjs @ayjayem Your opinion ?


You are correct about the current design of the II. In the current design all devices that are added to an II are equal in power. Therefore, the whole II is only as secure as the weakest of the devices that you have added. If someone steals you oldest phone and overcomes the weakest fingerprint scanner then he can take over your entire II and lock you out. Similarly, the attacker can also take over if you use a compromised browser or sufficiently compromised OS and log into

So here all devices added to an II are on the same level and control of the II is defined by an OR condition: device 1 || device 2 || device 3 || …
Here, the recovery phrase is just another device like any of the others, just not a physical one.

What you are proposing is to introduce two levels. Devices on the lower level can only manage devices on the same level whereas devices on the higher level can manage all. So if a device on the lower level gets compromised then a device on the higher level can step in and kick out the compromised one and a complete takeover is prevented. Multiple administrative levels do not currently exist in the II. Whether they are needed is up for discussion.

A couple of points to guide the discussion:

  1. Account recovery through multiple administrative levels can be offered by the dapp. It does not have to be in the II. The NNS already offers that. You can configure a “hotkey” principal for voting with your neurons (that is the lower level) and a main principal for ultimately controlling it (that is the higher level). The main principal can reset the voting principal. You can use two principals that come from different IIs, basically achieving what you want. Any dapp could offer the same. For example, a social network could allow to associate two principals with each user account instead of only one.

  2. It is only for some applications, that a temporarily compromise is not as bad as a complete takeover. The case of locked neurons are such a case but that case is rather special. For a social media account you can also argue that a temporary takeover is not so bad, just a couple of posts in your name, but you would prefer that over completely losing the account. For a wallet of tokens or NFTs on the other hand a temporary compromise is as bad a complete takeover. The attacker can sell everything in your wallet immediately. So the multi-level administration will not protect you. Therefore the question is, isn’t it better if the dapp manages this along the lines of 1. rather than the II?

  3. The II is primarily designed to prevent people from losing access and a convenience feature. It is not meant to protect high-value assets. To prevent losing access you will need multiple devices on the higher level. Just one (like one seed phrase) is likely not enough.

  4. If such administration was part of the II then how exactly would it look like? Is two levels enough? How many devices on each level? What is needed and what is feature creep? Are we introducing new foot-guns that lead to people locking themselves out?

I think the discussion is going to be a long one and that is the reason that the II is as simple as it is now.


I was starting to get too tired to work out this problem and its solutions so precisely, because I have done it several times already. So I lost my energy and got used to talking about it for nothing. This is why my introduction is superficial. But @timo, thank you very much for your sharp clarity ! You gave me hope back. I agree with your brilliant complete post. I think you all said ! But while waiting for a full solution, I think we could just define a seed phrase request in order to avoid this main issue : the loosability of II forever. The seed phrase is already defined, I think that defining this function would not be too cumbersome to be handled quickly and would reassure a lot of people quickly.

About your point 2., at least, a temporary compromise would not threaten our staked icp, so a temporary compromise is quite good in comparison with the current total loss of our identity and then of our neuron and its icp in case of compromise.


I wonder if this has already been exploited: My NNS is out of control,Please help me

1 Like

I know a lot of people refusing to stake their ICP in the NNS because of this risk. If several other cases like the one linked by @lastmjs, the word will spread very quickly. An article against Dfinity or ICP could be dramatic, and even if the problem was solved once the article written. It would take a lot of time to heal of this. We have to stop underestimate this problem. ICP can’t be associated with such irreversible hack whereas it says « tamperproof » everywhere. People will tolerate hack, but not definitive hack. This problem could concern every each one of us. @zire

If a hacker obtains physical access to the laptop AND the yubikey (which enables changing seed phrase), there is no measure by any institution in the world that can be deployed to prevent this identity from being stolen, whether it’s CIA, FBI, NSA, or DFINITY. This is very likely the case for @xiaobing .

It’s very unfortunate that this has happened to Xiaobing.


I don’t agree, there is one : just make impossible to remove the seedphrase without having to enter the seedphrase in the first place to do it.

I can’t understand why this simple function is not installed, it would prevent against any definitive loss of Identity and neuron.

If this was set, sooner or later, anybody could take control back, cause the hacker or stealer would never have removed the seedphrase, given the fact he would not know the seedphrase to enter in order to remove it.


Forget the yubikey, just think of someone having installed iPhone or Mac as devices, in one instant, it can be stolen, and the stealer can remove the seedphrase. So, yes, you did not have other reports yet, but a lors of people are not using ICP on their phone, cause they know about this security lack.

Just set the necessity of entering the seedphrase before removing it, and the whole problem disappears ! For example, I could use ICP on my phone, cause in the worst case scenario, I would lose temporarily control on my identity and my neuron, but as my icp are staked, the hacker could not steal it, and I just would have to enter my seedphrase to take control back and remove his devices.


Hi Roman. I’ve been trying to understand your concern/request and I think I’m following your logic now.

I think the scenario your describing is:

  1. The attacker has compromised a physical authentication device (laptop, yubikey, etc.) somehow.

  2. The attacker used that authentication device to clear out all other authentication methods, to include the generation of a new seed phrase and removal of the old seed phrase.

What you are requesting is that II should only allow an existing seed phrase to be removed if the previous seed phrase is entered correctly first. By doing this you are giving the original owner the ability to recover the account even if one of their other authentication devices was compromised? Is that correct?

This would of course assume the user has not stored their recovery key in a digital form that has been exposed to the attacker. But I think I still see value in your recommendation given the prior issue linked by @lastmjs.


EXACTLY !!! Sorry for my English my friends. @lastmjs @zire, @LightningLad91 expresses better than me my opinion, read this :point_up_2:

1 Like

You have perfectly synthesized my opinion.

I have been recommending this for months now.

1 Like

Thank you @LightningLad91 for paraphrasing the suggestion from @Roman . I understand your suggestion now.

Have you guys seen such security measure being deployed in any other L1/L2 blockchain? I’m curious to know how others in the industry are tackling this issue. A few examples would be helpful.


I only saw the radical no removability of seedphrase, like Ledger does with their hardwallet for example.

I think that if it is not possible to set, if we have to choose between :

  • changeability of the seedphrase too easily (so, without having to previously enter the original seedphrase before removing it)
  • impossibility to remove it, we would have to choose impossibility to remove it.

We should choose the second one.

@nmattia ?


Unfortunately, I am relatively new to the blockchain world (the IC was my first exposure) so I would not be able to reference any services on other networks. Perhaps @lastmjs knows of a few.

IMO, It does seem like it would make sense for the seed phrase to be protected in this manner. Unlike centralized Web2 accounts, these accounts cannot be recovered by proving my identity to a help desk technician. Requiring an existing seed phrase to be entered before replacing it seems like a logical protection if you’re working under the assumption (like I am) that the seed phrase is put in cold storage for disaster recovery and not being used to login frequently. This still puts the onus on the user to store their seed phrase offline (in my case a safe).

That being said, I’m not an II expert, and I’m confident Dfinity can come up with an adequate solution.

Edit: I realized I made a logical leap regarding my web2 reference. To clarify, I’ve used several Web2 services that required me to authenticate with an existing device, enter an existing password, or recover via email/text in order to change a security setting on my account. In Web2, if these authentication method are compromised your only real option is to prove your identity to the company/organization that operates the service and has authority to manage your account directly. You typically prove this with a SSN (if you’re in the U.S) or some other unique identifier that the user is expected to protect. There is no equivalent out-of-band recovery method with the II and I see the seed phrase as being a potential solution. But that does not work if an attacker has compromised an authentication device and is capable of resetting the existing seed phrase.


If you produce seed phrase key shares out of the seed phrase ( look at for a prototype) and distribute those key shares to friends and family, you have,essentially, an out-of-band recovery. Now you would need to call your friends and family for social recovery of seed phrase.

In that above context, having a seed phrase that is locked(i.e. cannot be changed by ANY other authentication means except knowing the seed phrase), completes the picture beautifully.

Incidentally existing means to authenticate/recover should always be 2FA; even in the current context. This can be accomplished by ledger-nano acting as FIDO device; for example (because you need both the device, ledger-nano, in this case & the pass code to the ledger nano)


And with the ability of canisters to hold ICP, it is now possible , I think, to have this mechanism be built into the IC for your friends and family to act as " the company that provides that service of recovery". I will write this up.


I’m all for social recovery. I look forward to the day this is possible.

I agree that having a locked seed phrase would compliment the social recovery mechanism. Otherwise, the attacker can just remove all of your approved contacts.