Immediate Action to Protect Internet Identity w/ Seed Phrases

[lastmjs]

Why can’t we turn an existing seed phrase into a seed phrase protected?

[mparikh]

That (Why can’t we turn an existing seed phrase into a seed phrase protected?) would be great! I dont relish the thought of going through my “globaly distributed seed recovery mechanism” for DR.

[dostro]

Simply because this thread has highlighted for me the community’s desire to keep II slim, which for me translates to “small, incremental changes”. It’s also arguably a bit more secure to wipe your insecure recovery phrase in favor of a protected one that you can be assured at that moment only you have access to.

In favor of incrementality, I’d vote to build protection in first and convenience in next. Counter arguments?

[frederikrothenberger]

Because right now seed phrases can be deleted / changed.

There surely exist some users who still have access to their WebAuthn Credential (YubiKey / Biometric login) but no longer know their seed phrase. There might even be users who know, that they have lost access to the seed phrase but still did not update it (for whatever reason). And by just locking everyone’s seed phrase we will create a lot of unhappy users unable to use the seed phrase feature at all. This is why the seed phrase locking feature has to be opt-in (and imho should require proving that you still have access to it, again because otherwise people will soft-lock themselves out).

Internet Identity should be an unopinionated platform that everyone can use how they see fit. We recognize that right now there is a deficit in functionality for those users who would like to differentiate the access levels of their different devices / recovery mechanisms. It is a very high priority in our team to solve this.

Nevertheless, it is important to not make changes that

• limit the design space in the future in overly restrictive ways
• cause disproportionate amount of maintenance effort
• harm / restrict users

This is why we need to be careful about this change and cannot just lock everyone’s seed phrase.

[lastmjs]

I’m asking why we can’t choose to turn an existing seed phrase into a seed phrase protected, I am not suggesting we update all seed phrases to become seed phrase protected.

I just want the option to update my current seed phrase to a seed phrase protected.

@dostro if it isn’t as simple and would possibly be a bit more secure then I think it’s fine to proceed with the simplest possible implementation that gives the users the option to create a seed phrase protected. But I also don’t imagine it wouldn’t be that difficult to add the code to upgrade an existing seed phrase to a seed phrase protected.

Here’s the thing I was careful when creating my phrase and have multiple backups and everything. Now I’ll have to redo it instead of just clicking a button. That’s my personal bias.

[neeboo]

+1

I think 2FA adding/removing devices/phrases and Social Recovery are better choice for users

[dostro]

Ok how about this - since Internet Identity doesn’t have a concept of “update device” and since we want to make minimal changes to the backend, we could handle this from the frontend since a recovery method is just another public key:

• User chooses to convert seed_phrase to seed_phrase_protected in the UI
• UI retrieves the seed_phrase public key from lookup()
• UI adds the public key as a device with seed_phrase_protected keytype
• UI removes the seed_phrase device

I don’t think we need to ask the user to re-enter their seed phrase for this procedure because if an attacker is going through this process, they can easily just remove the seed phrase and add their own seed_phrase_protected

[nmattia]

Hi all, got some news!

Identity Labs, Internet Identity and @lastmjs met yesterday to discuss this; made a lot of progress including an implementation plan! I’ve started a new thread for anyone curious about the plan and progress.

There were some questions asked here that I think would be good to clarify once and for all, so I’ve also updated the FAQ. Should be live early next week.

Finally, we’re making progress internally on allowing external contributions to the Internet Identity repo, just pending some approvals. I’ll send out more info as soon as that’s done!

[sat]

Something mentioned in another topic, re-posting here @lastmjs for visibility and comments.

Protected Recovery Phrases: Plan and Progress

You created an Internet Identity anchor and used it to log in to the NNS dapp, where you staked 10,000 ICPs in neurons for 8 years. A few months later, an attacker steals one of the devices you use to authenticate. One very likely “device” to be stolen is IMHO a non-physical device, and that would in our case be the “recovery phrase”. Is there anything we can do to prevent this theft? Maybe we can require entering multiple authentication and/or recovery devices in order to remove the “recove…

More specifically:

One very likely “device” to be stolen is IMHO a non-physical device, and that would in our case be the “recovery phrase”. Is there anything we can do to prevent this theft?

Maybe we can require entering multiple authentication and/or recovery devices (i.e. n out of m total auth schemes) in order to be able to remove the “recovery phrase”? The actual required mix of the devices would be open for discussion, of course.

But thinking a bit more about it, it might make sense to have to do this for any removal of the authentication devices? Otherwise, someone could remove authentication devices one by one until only the recovery phrase is left, and then add their own authentication device, and then they have the “majority”.

[romulusp]

Maybe attaching “kyc” to neuron ?! I don’t know if that is feasible, but as a user i don’t mind to have a known neuron attach to my identity. If i will be hack, i only lose the interest. (what i understand in the future 2-3 year will be mandatory for blockchain to do kyc). Please excuse me if i’m wrong, my knowledge in blockchain and Kyc are limited and usually just follow the forum and don’t get direct involvement but having identity bounded with neuron is looking unhakable and i will have plenty of time(8years ) to make a proposal and have control back of my neuron. As a user , in my case , it will be the most desirable thing !

[Based]

Yubikeys with the pin too please, why was this taken away?

[paulyoung]

@sat

But thinking a bit more about it, it might make sense to have to do this for any removal of the authentication devices? Otherwise, someone could remove authentication devices one by one until only the recovery phrase is left, and then add their own authentication device, and then they have the “majority”.

Immediate Action to Protect Internet Identity w/ Seed Phrases

In hindsight this would make it impossible to remove devices added by an attacker. The difference with the recovery phrase is that there’s only one.

[justmythoughts]

@sat

@justmythoughts

I think you may want to change the proposal to require that 2 access points must be used to create a new access point, reset a seed phrase, or delete any other points of access to an identity.

This was the original idea I had behind a “2-factor-device” auth approach to adding or removing a device.

Immediate Action to Protect Internet Identity w/ Seed Phrases

@lastmjs Here’s a situation that would give me pause to approving this proposal. Let’s say I wrote down my seed phrase somewhere, and I lose it. I don’t know that it was destroyed, but I know that I lost it. If this proposal passes, I will have no way of generating another seed phrase, and if my seed phrase is found or stolen by someone else, they have access to my account. I will be worried for the rest of eternity that someone will find my seed phrase and do who know what with it. I think y…

[sat]

@Immediate Action to Protect Internet Identity w/ Seed Phrases

In hindsight this would make it impossible to remove devices added by an attacker. The difference with the recovery phrase is that there’s only one.

Aha, good point @paulyoung .
To clarify, here is one scenario:
Alice has auth key A + recovery key R. An attacker obtains access to the recovery key R. They can enter R to remove A, and even add a new key C. Now they have access to both R and C and it’s game over for Alice. The attacker could also replace R with R’, to be safe.

Would a requirement for 2+ authentication methods in order to remove entries help? Even that doesn’t work in all cases, since:
Alice has keys A+R. Attacker obtains access to R and adds a key C. Attacker uses C+R to remove A, and they again have complete control over the account, i.e. both keys C and R.

And how about introducing multiple recovery keys?
Example: Alice has keys A+R1+R2+R3. Any of the R1/2/3 can be used to recover access to an account, BUT the majority of R1/2/3 needs to be used (so in this case 2 out of 3 recovery keys) in order to remove any auth or recovery method.
Now, an attacker obtains access to say A or R1 (assuming it’s unlikely that they obtain access to all R1+R2+R3). They can add their own key C, but they can’t change the keys R1/2/3 since they do not have the majority of the keys.
There could be N (more than 3) recovery keys, to further improve the account protection.

[paulyoung]

I’m not sure; can’t an attacker add enough devices to give themselves majority?

[sat]

We could maybe introduce this limit. There needs to be exactly N recovery keys, where N is a fixed number, either fixed by the system or provided during account creation.
This means that not more than N recovery keys can be added. And to change any of the recovery keys, the majority of the current N recovery keys needs to be entered.

[Zane]

This thread started as a band aid fix to II’s security issue, but seems to have gone a bit further than originally intended, at this point why don’t just add customizable permissions to auth devices? UX wise is much better than limiting number of recovery keys and requiring majority to do any change. Not saying its a bad idea but for most users it’d be quite clunky and unintuitive imo, it would be nice to have as an additional optional layer of security.

[sat]

@Zane

at this point why don’t just add customizable permissions to auth devices?

I’m not working on II so I’m not opposing But we need to keep in mind that a novice (inexperienced) user won’t know which permission is safe and recommended. So adding customizability may not solve the problem for all users – and especially for the most risky (security unconscious) part of the IC users.

[jsull9]

Thank you SO much for this thread! My apologies in advance for the length of my post/ questions… I have a few questions about long-term storage and using the FUBI keys. Is there a way to just use a spare flash drive as a FUBI key? If not, are/is there a specific brand of FUBI key to purchasing that works for the IC identity? I am concerned about only using the seed phrase created on the computer (mac os), then saved on paper. There is still room for the seed phrase to be vulnerable I was told (which would allow someone full access to my account)… So, I am trying to get the appropriate hardware. I stake (and am fine with it) on the NNS directly, however, down the road if my account becomes of any tangible value I want to protect myself ahead of time, to prevent said experience. I like the Ledger hardware wallets for the ability to have a backup in case damaged or lost. I would prefer that type of concept in any reccomodations.

Also, say I pass away and in my will, I leave my digital assets (ICP coin) to x,y, or z. How can I make sure that person(s) have access (or ability to follow written instructions on how to access) this account? If using the FUBI key then they can plug that in and use it that way, however, what if it is a fingerprint sensor? is there a backup to prevent that?

[wpb]

If you search the forum for @Manu then I think you will find some really good posts that he has made addressing this topic. Hopefully they are not too hard to find. Additional names that have been involved with those conversations are @Roman and @LightningLad91, so perhaps a combination search will provide a better filter. Each of them have expressed concerns about proper security and recovery in the past and I believe @manu has offered an explanation and solution.