I’m in favor of doing this.
I think it generalizes to “You can only remove a device/seed phrase by proving it’s in your possession”
In the case of both devices and seed phrases, it would mean that you could never remove them if they become lost or stolen. Methods of marking them as such could be introduced but they could also be used by a malicious actor with a compromised device.
Good point, just wondering if that already requires to enter the seed phrase?
I would be in favor of no as it is currently unprotected.
I think you’re absolutely right that two levels are the future proof way of doing this. But it’s better to have a simple solution with improved security right now.
This can be moved even further with multi level and more fine grained control over devices. But this will certainly take significantly more time to implement.
We propose this to have a short term solution.
I like @dostro’s design showing the padlock in the management screen. I think that may be the right way of presenting that to the user.
I don’t think it’s reasonable to implement an intermediary solution in the backend. The additional complexity over the opt-in locked recovery phrase is minimal, but the effort to implement a partial solution and then generalize later may be significant.
For the frontend, things are a bit different. Migration is easier, so we could go with a simplified solution first. But there’s actually a variant that has much better security properties than the plain recovery phrase: Using a Ledger hardware wallet with the FIDO U2F app as web authentication mechanism and using that as the recovery key! (You get back-up security since the key is derived from the seed phrase as well, but you never have to enter/read the seed phrase on your computer.) So I think whatever we build for the recovery phrase should also work for that type of setup as well.
@frederikrothenberger @nmattia please also chime in with your perspective on implementation complexity.
I totally agree with this. Very confused: when want to delete the seed phrase, just press the x, and then it disappears right away, that’s not good for security.
@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 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.
If the identity only has 1 access point (the user only has 1 key/device), then a single device can create new access points, reset the seed phrase, and perform all capabilities. Once there are now 2 access points (not including the seed phrase), the user is required to use 2 access points for any of the create/reset/delete access point capabilities.
I’m thinking this would be like Internet Identity’s version of 2 Factor Auth.
A few examples:
I think this does a good job of protecting identities that have done the legwork to create more than one access point into their identity, without screwing those of us that do a great job safeguarding all of our identity keys, but accidentally lose our seed phrase.
One issue/hole I see with my solution above is the case I’ve quoted, where an attacker could use a seed phrase not to delete devices, but to quickly add enough devices until they meet the 2 device threshold required to lock people out.
I think there’s potentially a way to stall such an attack, such as new devices can not vote to delete or reset any old devices for a particular amount of time or a one can only add a 1 new device per week, but I’m wary to go down either of these solutions as they introduce additional complexity.
I’m going to let my concern and idea above just sit for awhile, and maybe the community can find a solution for the situation where I lose my seed phrase.
Also making the yubikeys require a 6 digit pin to log in ontop of touching the physical button
Was like this at first (June 2021) and suddenly stopped asking for the pin.
Would be really great to have this back.
First thank you @lastmjs for starting a new thread. I hated the idea of continuing the old one, as the title was extremely misleading.
Regarding the proposal to make the Seed Phrase somehow “promoted”, I have a couple of thoughts:
Caveats:
It would be nice to be able to choose what device is designated as “admin”. It would make sense to support more than the default seed-phrase, if it’s possible and not too much work to implement.
Generally in support of this idea moving to next steps.
But like these suggestions too…
Can we have two or more seed phrases simultaneously for each II anchor? Then:
Now, if one of your seed phrases is stolen, the thief cannot delete your other seed phrases, but you can delete that seed phrase immediately and then generate a new seed phrase.
(Note: A seed phrase is not considered as a device here.)
respectfully that is really over complicated lol
You can still have just one seed phrase, but if you want, you can make your account much safer by using multiple seed phrases. This can be especially useful for the 8 year gang.
And I am the one who had been accused of being a troll there… From a person who, even months later, after having had bad interactions with several members on that previous thread, takes the time to add fuel to a fire by sneakingly criticizing a guy who left the previous thread because of such an attitude, like several other persons, like @LightningLad91 who does not need to prove his value. I see that the attitude has stayed the same. I left the previous thread, I did not mention what happened there, whereas I was more legit to do it, but you do it, whereas you messed it up. Very odd. Very.
So, according to you, the title was misleading and you praise Jordan’s new thread, who says :
“Lack of security” and “major security vulnerability” mean the same thing, but nevermind… Again, odd logic.
Even after months of this conversation that I also disliked just because of your attitude (to say “hate” like you do sounds a bit a drama to my ear,) you keep going on by mentioning it without any utility to this mention. So since you evoked indirectly me, I answer : I really hope that you won’t mess this thread like you did with the previous one, by making leave several persons loyal to the IC, like at least two voting members of the known neurons. And don’t hesitate to not answer to me, here, elsewhere.
And everybody knows about the FIDO, but like @diegop, @timo and @skilesare said it multiple times, the FIDO must be completed buy the II seedphrase, because we can’t count fully on FIDO.
Maybe you should reread the previous thread. You know ? The one whose you hated the title, to not propose the same solutions we already states like inaccurate there. To not make us forced to repeat the same counter arguments here, and move forward with real solutions.
Regards
Purpose of this thread
Internet Identity Labs, a community team building NFID, and in collaboration with Jordan, are willing to devote time and resources from their projects to write the code for this work.
Our intention is to make one small but mighty iterative improvement, not to how all of the Internet Identity service works, but rather one very specific component. However much we’d love one or all of these ideas implemented, in practice any of them would take many months to discuss, architect, and implement.
The feature in question is: An opt-in feature where users wanting to remove a seed phrase must first re-enter their seed phrase as confirmation they’re in possession of it (I posted above what it might look like).
We believe this is important for the specific case when an attacker may be in possession of one or more of a user’s authentication device(s) and attempts to lock the user out by removing all other devices, including the seed phrase. If this feature were implemented, the attacker wouldn’t be able to remove the seed phrase, giving the user a fighting chance to regain control of their anchor.
Of course there is more work to do - What if the attacker knows the seed phrase? What if the user lost their seed phrase? How could device management generally be made more secure? - and Internet Identity Labs is devoted to taking these on over time.
For the immediate term, please respect this topic’s scope:
raise agreement or challenge for an opt-in feature of seed phrase re-entry prior to its removal backlog out-of-scope questions, ideas, and discussions to new threadsThank you all for the healthy discussion!
Losing the seed phrase shouldn’t be a problem if you have devices on top of seed phrase linked to the II, so like @dostro says it’s a good enough temporary solution for users to stand a fighting chance against bad actors.
Totally appreciate the desire to block scope creep, but this is a community proposal and not a company driven feature or a PM adding features to a sprint you already have committed to.
Getting support from the community means considering not just one change, but how this might impact future changes and additional issues that may arise as a result of this. It also means at least hearing and considering other solutions and edge cases from the community. This is also the type of support all of us as IC application developers will need to do once we hand governance of our applications over to the SNS.
Requiring entering your seed phrase in order to replace it, means that if you lose your seed phrase there is no seed phrase replacement option. This is directly related to the feature your are proposing being implemented, and so at least considering and planning out how this might be dealt with afterwards is part of the proposal as far as I’m concerned. We don’t want a feature being implemented that has an unpopular side effect with no abstract plan for a solution, especially if the new feature is too “sticky”, or is hard to change, build upon, or revert in the future. Part of rolling out a new feature is also considering whether it is a “one-way door”, or a “two-way door”. In other words, is the change reversible or permanent? - permanent changes require A LOT more planning, design, and critical feedback before going ahead.
You may very well have the “best” solution, and I am by not means as experienced in the security and identity space, but many times software designs and solutions improve the more eyes and feedback they get.
Your comments suggest that you and @lastmjs have defined an issue and a scope before listening to the full list of user/community feedback and will go through with you implementation regardless of feedback, which is sort of the opposite of working backwards from the problem and listening to your customers’ (NNS users) feedback and using that to develop the scope, solution, and UX.
What type of limited feedback scope are you asking for? Affirmation? Security flaws? Might be good to put that in at the top of the initial post topic of you don’t want community suggestions for features.
I agree with you completely and apologize if my phrasing came across as anything but a very specific suggestion as a topic for this thread, request for its analysis, and now an action item to analyze the long term consequences (originating as a challenge earlier in the thread)
Of course someone (or people) will be involved in surfacing those long term consequences, and hopefully some of the folks mentioned on this thread will have time to give us this input next week, but we could think of things ahead of time - what are your thoughts in the following cases?
Of course I understand we can’t yet discuss the second and third points specifically before we know exactly what those are, so perhaps we could start with the first case? What do you think of implementing this feature if there are no long term consequences?
Thanks for the response and glad we’re on the same page - I get where you’re coming from.
Here’s what I see as a few consequences of this feature.
A seed phrase now becomes more powerful than any other type of access point. It can reset the seed phrase, and create and delete other access points.
Unintended consequences
The seed phrase, which is arguably the most hackable (moreso than a biometric or hardware access point), is now the most powerful access point of all. No other access point can reset the seed phrase, but the seed phrase itself can do everything.
I am now forced or highly incentivized to create a seed phrase - if I choose to not to set a seed phrase and an attacker gets access to my account, they can create a seed phrase that I do not have access to and I have no recovery mechanism. The first actor to set/wield the seed phrase owns the account.
If one loses their seed phrase, they are totally screwed if someone finds it (and no ability to reset it).
We also need to think about all different types of NNS users, such as the more passive “set-and-forget” user, and how this might affect effect their experience logging in to the NNS in 8 years through their phone if they lost their seed phrase and want to generate a new seed phrase. The active user who’s staying up to date with all of these changes will have no problem whatsoever, but with such a change we have to think about all of the II users.
Is this a 1-way door?
I’m not sure. I think there’s a way to make this change reversible (say we decide to move in the future to an Internet Identity version of 2-Factor Auth for creating/deleting/resetting access points), but it really depends on how this is designed and implemented in the code.
The more we segment the identity security options (say make this feature opt-in), the harder it becomes to make new features that are backwards compatible.
I think this can completely be done in a way that’s backwards compatible, but I’m just trying to bring up as many edge cases and concerns as I can in order to ensure that whatever change to Internet Identity keeps all of this in mind.