No one should be able to remove devices that easily specially recovery. One of the main features I like is locking neurons as it adds to the security of the system. However if someone can get your yubikey, seed or whatever and lock you out that is a big problem. There should be a timeout phase for removed recovery devices. Owner should be able to choose time such as week, month or year. If user sees that recovery key is about to be unlocked and removed they can then take action to remedy the situation. The owner can initiate a process to recover the account. Maybe then there is an SNS social component that decides who is the real owner based on Neurons the person follows for the recovery process.
4 Likes
Having easy to use Trezor support wouldn’t hurt as well.
Wow. Just gave this thread a read from top to bottom, and I’m troubled with what appears to be the development community’s obtuse reaction to this valid concern (I don’t know all the players so I’m really just guessing here). “Don’t trust the II” - is that really the message we want to send? Honestly I would never have gotten involved or excited about this project if it was presented that way to me in the first place.
There is a simple solution that will increase trust in the system - Fix the II recovery mechanism (there have already been some good ideas discussed in this thread) such that it can actually recover an account that has at least one compromised key. Yes, that’s not necessary if we don’t trust the II, or if we exercise perfect security protocols - but, that’s not the point. The point is we’re trying to build a trustworthy system and that requires some level of fault tolerance. No system will be perfect, but ‘better’ is right in front of us.
6 Likes
At this point, it is NOT the messaging that matters. It is what it is, currently. To pretend otherwise is not wise, IMO. I am not trusting II CURRENTLY with my store of value because the experts are telling me NOT TO.
Also it’s NOT ALL doom and gloom. I am convinced that II is leaps and bounds beyond the standard userid/password thingy. This tool is very very powerful if wielded properly. Also alternatives (such as live distros ) are perfectly reasonable for most. As some have pointed, that alternative would likely require a physical compromise to be risky.
The above said, my personal risk tolerance with financial losses is very low ( I don’t mind ups and down in the marketplace. I do mind preventable and foreseeable losses; it hurts my ego).
That said, we are ALL looking greatly forward to making II better. As you see, there are different nuances that different folks bring into the picture and I can see their point of view. We are NOT apathetic. However as many have said, this is a long conversation.
4 Likes
Oh boy. I’m a bit disappointed that the general feeling is one of doom and gloom. Here’s my attempt at providing some context and a recap of what was discussed, and why we should be positive rather than negative about this. Wall of text warning.
- Key security concepts - Onions and Chains
A key concept in computer security is risk mitigation. As we have so far been unable to design a 100% secure system, we are using mitigation strategies to limit our exposure. One such strategy is to use layers of protection (hence the onion analogy). Let’s say you might use a strong boot password, then a strong user login password, then a service like II. Each step is designed to protect against a range of attacks, and together they’re supposed to protect the entire system.
The II in particular is designed to protect against a multitude of scenarios when services are compromised and passwords leaked. The II also works against eavesdropping, by never transmitting the actual private keys, but signatures and delegations. We can even say that the II protects against specific cases of local system compromise, say a keylogger or local file access.
However, in order for the II to work correctly, it must make some assumptions. Some of them are based on the browser. In order for the II service to work correctly we must assume that the browser is trusted, and that what we see on the screen is what’s actually happening. Hence the chains analogy. The browser becomes the weakest link in the system. If that is compromised, a normal usage of the II service is rendered not safe.
Wanting the II to be immune to a compromised browser is a bit of a having the cake and eating it too conundrum. There’s a balance of risk vs. ease of usability that you’re willing to take. The II has it’s role, but if that’s not enough for you, you can always move to a dedicated hardware wallet. (as it’s recommended for any other crypto out there). Or you could go for the poor man’s hardware wallet - an airgapped system.
- The needs of the many vs. the needs of the few
We need to define and understand the difference between a target of opportunity vs. a target of a determined adversary. That is to say it is much easier to protect yourself from a random “bulk” phishing campaign than it is to protect yourself from a state actor attacker that wants your ICPunks NFT. Just ask Bezos and his dong pictures.
While Dfinity and the team behind the II can do little to protect your dong pictures, they can and have decided to design the II to handle the most common dangers that a user will face on-line. Those are the common ones you have already learned about - reusing passwords, phishing attacks, keyloggers, etc.
Whenever someone thinks they have found a problem it is prudent to reflect on the actual impact of said problem. Especially when the “solution” implies changing core systems. Will the proposed change even do anything? Will it help the needs of the many? Will it improve anything? We seem to have put emotion and ego before facts and logic in this thread.
- Newton vs. Einstein
Let’s assume there’s a student that needs some help with space travel. They ask their professor if it is true that we can go to the Moon with just Newtonian physics. “Well yes, says the professor, of course you can. However, if you want to use GPS you will find that Newtonian physics is incomplete, and you’ll also need Special Relativity”. Now, imagine that student going something like “OMG the professor said that NEWTON IS WRONG!!! what are we to do! DANGER DANGER, watch out for the apples, they’re gonna start falling sideways!!!”.
I used this contrived example in an attempt to bring home the humor in some of the replies that unfortunately missquote @timo and assume the worst in what they’re saying. In fact, if you carefully read their answers, they’re just like the professor in my silly example, patiently explaining that for every scenario there are better and better approaches to security. And, if you ask a domain expert in cryptography what the best practices are, of course they will suggest the safest solution from a mathematical standpoint. However, that is NOT to say that every other usage up to that point is WRONG, or DANGEROUS, or whatever gloomy term you might find. It’s just that some solutions are more complete than others. Or, better suited for each need.
- Implementation detail vs. LACK OF SECURITY!!!
I believe we’ve reached a point in our context where we can tackle a key point: Whatever recovery strategy the II ends up implementing, it will NOT have any relevance whatsoever on the actual SECURITY of the II system as a whole.
Another way of putting this point is that you are not more or less safe using the II now, after reading this wall of text than you were yesterday or two weeks ago. And you will not be any more or less secure two months from now, even if dfinity ends up implementing one recovery strategy or the other. At the end of the day, the goal of the II should always remain to serve the many, protect against as many attack avenues as possible, and be as user friendly as possible. None of these design goals will change if the recovery strategy is being altered.
The II will continue to be as secure as possible, until an actual security bug or problem are found. Please understand that changing the recovery strategy is just an implementation detail. The actual account security is not affected!
Having a different recovery strategy could help mitigate some of the risk, but at the end of the day it’s still a matter of how much risk are you willing to tolerate. Alas, we’re back to this being an OPSEC problem rather than a II security problem.
- Continuing the discussion and recovery strategies
I think we all agree that the recovery strategy could be a valid avenue of discussion. While it needs to be said that it is NOT an easy straight-forward decision, and that there are at least some factors to consider, it is a worthwhile discussion to have.
Continuing to have it in this thread, however, will only create more confusion and - as we see - this doom and gloom feeling from a lot of the participants. IMHO this singular item should be taken in a new thread, with an appropriate title, and worked on by the interested parties.
Recap:
Lacking any evidence to the contrary, the II is currently as safe as it was designed to be. IF you feel that YOU are better off using other solutions, they’ve been offered. You can make the II as secure as you’d like, you can add multiple auth policies to the NNS, etc. Just re-read @timo’s replies.
We’ve gone from the needs of a particular individual’s alleged problem to “ermigod this is insecure” in the blink of an eye, with not much merit behind it. I hope people realize that with great “power” comes great responsibility. While a strategy of raising a storm in a teacup might work on socials, it’s quite counterproductive on a dev forum, and it’s a bit disheartening to have a Principal Researcher take time and explain the situation, and then ignore everything they said and “conclude” that ICP has a problem.
10 Likes
No problem. Developers always have the right to say “It is what it is; just deal with it.” to the user.
As someone who has already had my personal information compromised, due to factors I couldn’t control, I was just hoping that the developers behind Internet Identity would give me some way of proving I own that online identity in the event it was stolen from me. It’s not about the crypto or the loss of tokens. It’s about the loss of my identity. Losing my II right now probably doesn’t mean much today but I could see it meaning a whole lot in 5-10 years.
If that’s not the vision for II then peace, i’m good with it an will adjust my risk mitigation strategies accordingly.
Edit: Fwiw - Getting hung up on the “Lack of Security” title is silly. “Security” is a very broad term that covers a lot of different domains. Not providing an effective account recovery mechanism (it’s not effective, that has been proven already) could certainly be perceived to be a lack of security.
5 Likes
When I first use the II back in May, there was no Seed phrase recovery. Why has this been implemented then? I assume the answer is that Dfinity have found a way to compensate some security issue (Browser, etc) by implementing a Seed phrase recovery system. We are not saying IC has a problem. A compromised browser is not a IC problems directly. But since IC is using browsers, a compromised one become a problems for IC. We are saying that the II can certainly improve, both as security (2FA if not 3) and and efficient recovery.
I really hope that this is more then a discussion that will be send to garbage. I am not sure how many threads are taken seriously and lead to real action. I really hope this one will lead to action for both the benefit of all users and for the IC itself.
Can you imagine if someone has his computer stolen at home while he forgot his Yubikey in the slot and the thief take control of the victim ICP NNS account (with many thousands of $), all his DEFI investment on IC, all his NFT’s, all his identity on all social media. All at the same time, because no 2FA login, no efficient recovery system and no one to address his situation?
While some people may say not to leave your key in the slot and put your dedicated computer in a safe that weight 2000 pounds, this is not real life for average people. Does Dfinity want have mass adoption or not? It will never happen if this first layer is not improved. Maybe it is time to think about the “average Joe” people and not only the programmers.
Instead of spending time at working to find arguments for Not doing anything, I suggest the experts to work at finding and programming real solutions for a real concern.
EDIT: BTW, I am a programmer for over 20 years in medical field, not on IC or blockchain though. Security and recovery are taken very seriously in the medical field and are #1 priority all the time.
6 Likes
This is absolutely correct. Identity management, account recovery, all of that, absolutely falls under the “security” umbrella.
4 Likes
If you are referring to that dude with the “lost” access, then that is far from what I’d call proven. You simply can’t know the facts behind that story. It’s a story from an individual, and frankly I have no idea why anyone is even entertaining that story. IMHO we (both the community and dfinity) shouldn’t touch that can of worms with a mile long pole.
Again, the thread seems to be running on emotion and feelings instead of arguments and facts.
1 Like
No. I’m referring to what @timo stated above. The fact is that these “recovery devices” really aren’t any different than your other devices and won’t help you recover anything in the case of identity theft.
What we are talking about is recovering from identity theft. Not preventing it.
Based on the way you spoke to @Roman earlier in the thread I imagine it’s easier for you to assume I’m just an ignorant user that doesn’t understand the impossibility of building a perfectly secure system. I assure you that’s not the case. I understand that it’s impossible to build a perfect system. What I’m requesting is that the system be resilient enough that it provides the user with a means to actually recover from an incident. Could that user also lose their recovery device? Yep, fully acknowledge that. But being responsible for safeguarding one critical piece of information and/or token is a lot easier than trying to protect all of them.
For example, I have to leave my phone and keys outside my workplace every day. I’m not permitted to bring them inside. My keyring has one of my yubikeys on it. What’s the solution there? Am i expected to never access my accounts at work so I can keep those devices locked up?
This is exactly why I don’t think it’s appropriate to put the onus for account recovery on IC applications. Many of these apps will wanted to be governed by the community. Do we (both the community and app developer) want to touch that can of worms with a mile long pole in the future?
All of that being said; I still recognize that I’m one user trying to justify a feature request from a group of developers. I also acknowledge that in a public forum like this that these discussions can be twisted by individuals with bad intent. So I’ll stop banging my drum and just move on.
4 Likes
Then we are in agreement. The discussion about recovery strategies is worth having. I do think there are arguments for both approaches, and it’s a discussion worth having. I don’t think this is the place to have that discussion, since it’s quickly becoming difficult to follow the discussion.
Was never my intention, and I don’t know where you got that impression, but my apologies if you felt that any part of my message was addressed directly to you. It wasn’t addressed to anyone in particular, except for the last paragraph, I’d say…
1 Like
Let summarize so everyone is on the same page:
1- This is a Dfinity DEV forum and we are taking about new safety feature that would need to be programmed. This is the perfect place to discuss this TMO.
2- Except very few post, the vast majority of post in this thread are very rational and not emotional at all.
3- IC is decentralize and belong to his users and NNS investors for voting.
4- In order to vote and get rewards, as heavily promoted by Dominic himself, we have to deposit and lock our ICPs in NNS neurons.
5- Normal investors in NNS are not interested to learn and use Air gap computer to achieve maximum safety. Would be very difficult, impossible, with all social, defi, etc apps to come.
6- II is very important for all actual apps (and all apps to come on IC) and we cannot afford to loose our II to a thief
7- We ask Dfinity if it would be possible to add 2FA to log in NNS (any combination of what exist now would be a good start). So a single mistake, like forgetting the yubikey somewhere, have way less chances for the NNS to be hacked
8- Because we cannot prevent II theft at 100%, we are asking if Dfinity could programmed a non removable recovery hardware device (like Nano ledger) so the creator would always be able to access and remove undesirable devices.
Only 1 approach and easy to understand. Adding basic security and basic recovery feature.
No matter what @xiaobing have done or not, I find disrespectful to call him ‘that dude with the “lost” access’. And I am wondering if he would have lost his access if there was option 7 and 8 already implemented?
EDIT: just read @diegop twitter post about Motion proposal on Long term R&D plans. Improving NNS security and recovery are in the plan. Great. Done deal. Matter of time now. Will be patient.
15. Internet Identity - Internet Identity is a blockchain authentication system built for and on the Internet Computer.This project suggests focusing R&D efforts in the following years to the following topics:
- a. Improve security of recovery method management in the II canister.
- b. Provide stronger, cryptographic unlikability guarantees with weaker trust assumptions.
- c. Performance improvement in generating delegations.
- d. Secure account recovery using external identity verification providers.
- e. Decentralized anonymous credential-based authentication.
- f. Better mechanisms against bots, e.g. based on web auth attestations.
- g. Support for devices without web authentication.
- h. Support Internet Identity use in native apps.
11 Likes
Fair point on the first part. As for the second one, assuming the story they presented is correct, he absolutely would have lost his access! I guess it gets pedantic at this point, and please don’t take it personally, but I think this point must be made very clear: the access would have been lost, and it would have possibly been regained, depending on what recovery strategy would have ended up being implemented in this hypothetical. It just happens that in that particular case revovery would have been a success story (since the neurons were staked for a long time). That might have not worked so well had the ICP been liquid.
Look, I’m not arguing against implementing a better recovery strategy, all I would hope is that I help bring people on the same page with some core concepts, so we can at least all discuss about the same things. We all have some beliefs about what the best next steps would be, it would be more productive if we’d all at least agree on the terminology 
2 Likes
I’ve read the thread entirely and the concerns about II security have risen more along it.
The II should have security protocols to prevent Internet Identity loss when someone’s device gets hacked or is lost.
I liked two above mentioned ideas which could work to achieve this. There should be some protocols involved when you try to remove a security mechanism, which include:
-
a countdown or a time gap from the time the request to remove a recovery mechanism is made until it deletes completely, with the ability to cancel the removal of it. It could be a week or more. (mentioned by @cyberowl);
-
having a notifications mechanism in which the user will be notified if there has been a request for recovery mechanism deletion or the creation of a new one (as @coteclaude has mentioned above) (I’ve seen a project working on some notification dapp, I think it was Dbox maybe);
These security protocols are useful only when the connected device is compromised. So, when the user loses his device or gets the notification that a deletion command has been given (from another device), then he can login to II and stop the deletion process and remove the malicious device. The user has one week to be aware of this.
When approaching this topic, we should have in mind that there is a difference between a compromised device that is already connected to II, and a compromised recovery mechanism. The best way to secure the later one, is by social recovery (as mentioned by @lastmjs) and the above points that I’ve mentioned aren’t useful.
*sorry for poor english 
7 Likes
Very sensible suggestions, I especially love the time gap
6 Likes
Must be added more security measure for people who using NNS app.
-
Seed must not be deleted or if it need to do then previous seed must be entered and also there should be a time format attached to it after that it will change like a week or 15 days time & it shoud be appear in the NNS app so that user can be known to this fact it will be changed after specified time .
-
Same should be applicable while we wanted to change the authorised devices . It should come with a time period attached with it . Its very scary and concerning that someone looses all his savings due to lack of security from IC. Would be happy to see a proposal for it asap.
1 Like
I don’t agree with the second point because in case someone takes your authorised device (your phone for example) and you recover your II in another device and try to delete the lost phone from your authorised devices then that would pose a problem, the malicious party would still have access to your II until the countdown is over, and could try to delete your new device or do some other damage to any other dapps you will be connected to.
Thank you for your reply , I think in this case 2FA will be more advisable like" authy " or Google authenticator or yubi key type solution to remove or add new devices . But seed must not be changed once it’s stick to any internet identity or its should be notified to the user by any means if any one try to change or delete it .
1 Like
Thank you @coteclaude (merci!) for the summary. I am concerned about security and Internet Identity. The NNS seems to have several issues that are currently pending. Leading me to these points:
-
As far as I understand if someone were able to access whatever method you use to authenticate (phone,ledger,yubi) they would be able to alter your seed phrase? So we are talking about vector of attack is entirely physical?
-
As far as I have read a proposal to fix this problem is adding a recovery device when neurons are staked. With a time period so long with so many variables that could happen, it seems that this needs to be ironed out before I am comfortable adding more to a neuron.
-
It seems that the proposal to return the ICP to the stolen neuron and back into @xiaobing 's account could have been totally preventable if the seed phrase wasn’t changeable. Is this an accurate interpretation?
Thank you, anyone, for humoring my questions, I think we all would like to see the project grow to a healthy and stable future.
1 Like