I would say that the original seed phrase can never be recovered. But an internet identity can be assigned a new seed phrase IF AND ONLY IF they can demonstrate possession of the old (existing) seed phrase.
2 Likes
What about just providing a Shamir39 tool to split the mnemonic?
2 Likes
If I’m understanding correctly, you’re saying that once you establish social recovery shares you would not be able to remove any of them unless enough signatures were provided to meet the threshold? So if an attacker were able to compromise one of your existing devices he/she would not be able to disable social recovery?
That sounds good to me but I’m concerned something like that would take a fair amount of time to implement. We already have one user who is in a non-recoverable state.
What would be the minimum threshold required? This may sound really sad but I don’t have a whole lot of people I would trust with the social recovery shares. For me, it’s more about trusting these (1,2,3?) people to keep track of their share so that when the time comes I can rely on enough of them to meet the threshold. Personally, I’d much rather stick my seed phrase in safe with a tracker and call it done.
I understand this may not be ideal for everyone but I think it’s good to provide multiple options and let the user choose what they feel comfortable with.
I don’t see this being too different from protecting your personal records. Sure I have online backups, but my most critical records are stored in a fire-proof safe and I don’t access them frequently
4 Likes
No. But even in this case, people would never have the patience of manipulating a yubikey before each impulse to connect to the web, mainly the more superficial but the more habitual and frequent like connecting to socials, streaming etc. If we had to do this to connect to Facebook or YouTube each time, it would have never spread. Plus, yubikey has a price, and plus again people would never bring their yubikey with them everywhere, but they surf on the web everywhere, so…
I think the seedphrase is the solution. Up to people to add devices later. But seedphrase has to be the security core, and has to be either unremovable/immutable without entering it before being able to remove/mutate it, or to be unremovable/immutable.
1 Like
Social recovery doesn’t have to be “social”. I think there are security benefits to being able to split up the recovery materials, even if you don’t place the secret shares with another human being. For example, you could create 5 shares and hide them throughout your house, a burglar would have to find 3 of them instead of just the one location where you currently store your seed phrase.
And then after the home invasion is over, and you realize 1 or 2 shares have been stolen, you can use the remaining 3 shares to remove the 2 stolen shares (I’m hoping that’s possible).
4 Likes
2 Likes
Indeed. In fact with pro crypto states like Wyoming , it could be a corporation that might own a key share (and presumably having more robust mechanisms than just a phone call to reveal its key share).
You probably WOULDN’T want to do exactly that because of disaster recovery considerations.
Yes…through mnemonic rotation
1 Like
Yes, I agree with you !
That’s a good point. I could certainly see the benefit of this. Especially if I wanted to keep a share in my safe and maybe another in a deposit box, and one more in a cloud back up, and so on.
So at the end of the day we are still “locking” the seed phrase but instead of entering the existing seed phrase to unlock it we would have to compile enough shares to meet the threshold.
2 Likes
Exactly. The other thing is due to internet identity’s level of indirection. This makes it possible to effectively do mnemonic updation. If some of the key shares are stolen/lost etc, provided you meet the threshold, you can change the mnemonic and assign new key shares to different entities. All old key shares become invalid.
2 Likes
It’s all about incentives. If you can prefund your disaster recovery so that every a disaster recovery drill occurs, you provide ,say 1 ICP, to each successful participant. That might provide enough incentive?
My wish is that Dfinity create a security team who would develop a strong security system for the NNS. NNS manage billions of $. No one, who steal your seed or your Yubikey, should be able to add and delete your devices so easily. We should have warnings, 2FA if not 3FA, confirmation on other device, etc.
And then, should develop a self recovery system where only the creator should be able to recover.
No voting or human should be involved.
And also plan a system for your family to have access if you have a fatal accident.
Dfinity team are the best creators I have seen so far. It should not be very difficult for these professionals to figure an innovative way to have the best secure system over all others.
Unfortunately, right now, I feel my Kraken account and my regular bank account much more secure then my NNS account. This can be changed.
IC is a new born, so is the NNS. Time will make it grow. Have no choice if we want mass adoption.
8 Likes
When I started using Yubikey last June, I was prompted for my Yubikey PIN every time I wanted to login in my NNS, which I loved. Then, after a NNS upgrade, it stopped asking for my PIN. Was it only a coincidence or a change in the upgrade?
Thanks for the research! This got me curious and I asked around for reasons why this might have been disabled. I think this is where it was disabled, and explains why: Discourage user verification by Dfinity-Bjoern · Pull Request #311 · dfinity/internet-identity · GitHub
So yes, we can have this back, it’s just that (right now) it’s not very useful. To sum up the description: if someone steals your Yubikey, then can pretend to be the Internet Identity webapp and request and authentication without UserVerification; then forward that to the canister. Since the Internet Identity backend/canister doesn’t check for that flag, then it doesn’t really help. The “only” case where it helps is if the hacker has only limited capabilities, i.e. if the hacker only tries to log in via the web frontend.
I am guessing this is still something though; alternatively we could also make the changes in the backend to actually check that the Yubikey/FIDO2 device was used with UserVerification set to preferred.
1 Like
Trying to clarify things, mostly for myself; there’s also a great summary here by @LightningLad91 and a great comment by @timo here.
If I understand correctly, this is the OP’s original problem: if any of your devices gets compromised, then the hijacker can replace all your devices (including seedphrase) locking you out completely. @Roman you also mention that, according to you, getting your account hijacked temporarily is not a “big” problem since all your ICPs are staked in neurons, and being able to recover your account using the seedphrase means recovering your neurons.
The idea proposed here is to make sure your seedphrase either cannot be removed at all, or cannot be removed without the user first entering it. This means that as long as you know your seedphrase, you can always log in.
There are some issues with this approach (some that have been mentioned above):
- What if you forget your seedphrase? Then you are stuck with a seedphrase which you cannot change. What are the consequences of this, especially if it was ever leaked?
- What if you don’t trust seedphrases (someone mentioned that characters appearing on a screen is not very secure)? Then don’t use seedphrases! And this issue doesn’t really affect you.
- What if the attacker keeps adding new devices, faster than you can remove them? That’s something I would be worried about. If the attacker has the means and knowledge to hijack one of your devices, they can do many things to always have a way in.
- Right now, the backend doesn’t differentiate between recovery devices and … regular devices, meaning the attacker could (for instance using
dfx canister call ...) add another seedphrase that the legitimate account owner could never change.
Furthermore there are some points I want to clarify:
-
IANAC – I’m no cryptographer but I think that “seed” phrase is a bit of a misnomer. As others have pointed out above, most blockchains must have immutable seed phrases, which are unique for a wallet. This is not the case of II, where “seed” phrases are just another device (although the webapp treats them somewhat differently). To convince yourself, create an anchor, add a “seed” phrase, remove the “seed” phrase, and add a “seed” phrase. The second one is different from the first one.
-
Internet Identity is not a wallet. Its goal is to be an authentication mechanism for the IC. Because it is flexible it can be made very secure (see below) but at the end of the day (as Timo mentioned above) it is only as weak as the weakest link in the (device) chain.
-
You probably shouldn’t use the same identity for your 30k staked tokens and for dscvr/distrkit/openchat. In one case (the staked tokens) you’ll want something that’s ironclad, probably with one or two hardware devices (like a ledger or yubikey) and absolutely 0 iPhone/iPad/Android devices. Those one or two hardware devices will be put in cold storage and you’ll use them every n years when your neurons dissolve. The other identity is one you use for social accounts, etc, that is stored on your day-to-day devices (iPhone, etc). Anchors are cheap, why not have many? You (hopefully) don’t use the same login (mechanism) for your e-banking and for Spotify, probably best to do the same on the IC.
-
It was mentioned that using a Yubikey/FIDO2 device with II is 2FA; as far as I understand it isn’t. Two-factor authentication is when you have two factors, typically a password and a yubikey. In II’s case, the yubikey is the only authentication thingy you use, since there is no password, making this not-2FA.
This is actually one-over-two factor authentication (or one-over-multiple FA…).
Maybe the problem here is better solved with best practices and documentation? Maybe we should have a page somewhere explaining the limitations of II as it is today, warn about pitfalls, and suggest workflows like splitting your IC presence between several anchors with varying security?
There’s also some confusion that keeps being brought up about the relationship between recovery devices and regular devices. They are treated kinda the same but still differently in the webapp, and kinda the same but still differently in the backend canister. This should be clarified, and we’re revisiting the UX a bit at the moment, but suggestions are welcome!
6 Likes
Dear @nmattia, thank you for you wise answer. I will answer following your points’ order :
Roman you also mention that, according to you, getting your account hijacked temporarily is not a “big” problem since all your ICPs are staked in neurons, and being able to recover your account using the seedphrase means recovering your neurons"*
I don’t say that is not a big problem, but a problem less big than the current problem of seeing one’s identity and neuron lost forever. This is just a “moindre mal”.
What if you forget your seedphrase? Then you are stuck with a seedphrase which you cannot change. What are the consequences of this, especially if it was ever leaked?
Let me ask you, what if someone forgets his Ledger Hardware Wallet Seedphrase or any other immutable seed phrases ? Answer : this someone loses everything, and that is why Ledger, etc. recall frequently about being so cautious with this seedphrase. But despite of this risk, they don’t choose a mutable seedphrase, cause with mutability comes the insecurity. I can assure you that no whale would buy Ledger if they had the same seedphrase mutability than ICP to protect the forgetters. In summary, currently, the most cautious or responsible ones have to pay by taking all the risks in order to allow to those forgetting or losing their seed phrases a way to recover. But with this, the whole security falls for everyone.
What if you don’t trust seedphrases (someone mentioned that characters appearing on a screen is not very secure)? Then don’t use seedphrases! And this issue doesn’t really affect you.
I am ok with this point, but this is quite a minimal risk compared to the current situation, and if one doesn’t use seedphrase, one uses :
- either a yubikey or ledger FIDO(U2F) which is inadequate with a fluid using of ICP ecosystem on an iPhone or even on a Desktop without having to connect an hardware every time before going to stream, on socials like distrikt, etc.
- or a device using biometrics, so easily compromisable ; then every persons with an amount that they won’t want to risk – whatever the amount (it can be 100k for a whale, but also $50 for someone with low income) – won’t use ICP sooner or later, cause of :
1.the fear of losing everything after a simple hijack or a phone/computer steal/loss
- the lack of fluidity of having to use yubikey/FIDO all the time.
What if the attacker keeps adding new devices, faster than you can remove them? That’s something I would be worried about. If the attacker has the means and knowledge to hijack one of your devices, they can do many things to always have a way in.
Not if enter again your seedphrase is accompanied by the question : “do you want disconnect all your currently connected devices” ? Like Facebook or Apple do after a password reinitialization : they give the opportunity to disconnect every devices at once. But, still, even if this is possibility was not implemented, and that I assume the situation you think about, this situation is very too rare, even exceptional, whereas current system implies an important probability to lose everything without any opportunity to take control back and that my approach gives the opportunity to take control back in the majority of cases. It is a matter of probability : but your way of arguing is like saying “the car seatbelt is not a solution, because in some rare cases, it can decapitate you while an accident, so don’t install any seatbelt in any car”. But think about the fact that your mother could have been killed by the seatbelt in the accident in which she just died is not enough to forget that she was not using the seatbelt when she had the accident and that she would have got better chances if she had used it. In our case : once having been hijacked forever and our neurons lost forever, the thought that the attacker would have maybe added devices faster than me would not help to accept the current system in the case where I would be hijacked forever, cause the situation is too rare. It is not about finding the perfect solution, but to quickly limit the current high probabilities of failure.
So I agree with you, the main risk is to have one’s seedphrase stolen, but the risk already exists and currently, if one’s seedphrase is stolen, one’s neuron too, and forever, whereas not with my approach.
Right now, the backend doesn’t differentiate between recovery devices and … regular devices, meaning the attacker could (for instance using
dfx canister call ...) add another seedphrase that the legitimate account owner could never change.
• This is in your hands 
- Agree
- Agree
- Dfinity MUST NOT argue that people just have to create several identities to solve the problem. One of maint “marketing” and attractive points of Internet Computer is : having now the possibility of not manipulating several accounts. Still : let us assume someone creates one identity only for staking, like me, it will never be totally quiet : the scare of being hacked will be already here with the current system, because of the previous points. Plus, let us assume I create an identity just for chill on the web, here is the problem : almost each NFT ICP projects are developing an “Engage-To-Earn” authentically allowed for the first time by the on-chain technology, so people will use their “casual” identity too engage, and generate NFT, Rewards, etc. and eventually will be scared of losing this “casual identity” too because of all their rewards accumulated, and if in order to protect their rewards, they send a lots of rewards to their first identity : the “wallet” identity, they will be even more scared about losing this identity dedicated for staking, but they will also lose a lot of percentages of rewards, because the more you have, the more rewards you earn. Simply think of someone having 1000 icp, this someone create 2 identities in order to have 2 neurons with 500 each : his yield will be so much lower. So, let us keep the “one identity” marketing, cause without this, the ICP is far less interesting. And the day where appears a blockchain with the one chain technology, and a better security, ICP is done. I even can say to you that I know project developing by thinking of avoiding this potential lack of ICP identity unity (if the unity of Internet Identity is eventually forsaken). Let us not forget that concurrency is everywhere, and that the identity will be a battlefield for blockchains.
@LightningLad91 @mparikh @lastmjs I let you complete or reformulate !
1 Like
I think there is a major misunderstanding here. The II was not meant to be used for holding stake in the amounts that are thrown around here. It is not about having one II or two different ones. You simply don’t use II at all for these kind of amounts.
II is a convenience feature for everyday use. It is not a security feature for long-term storage.
II is and remains a “software wallet” no matter how you use it, even if you use it with a Yubikey and even if your FIDO device is PIN protected. When you connect a FIDO device it is only used once to sign the browser’s session keys. After that all interaction is initiated and signed by the browser alone. Hence II is only as secure as your browser, regardless of how secure your phrase, biometric sensor or Yubikey is. You cannot entrust significant value to this environment.
The only safe ways to hold significant value is with an air-gapped computer and the proper tools such as quill or with a Ledger Nano connected to the NNS dapp as a hardware wallet. In the latter case every single transaction gets confirmed on the hardware wallet’s display and signed inside the hardware wallet. The browser is then untrusted. There is no II at play with the hardware wallet.
Using a hardware wallet is different from using a FIDO device to log into your II. The former is a true hardware solution, the latter is still essentially a software wallet. The two are not to be confused.
I think because of this misunderstanding the discussion is getting derailed. Whales don’t ask if they can have one or two IIs. Whales don’t use II for storing value.
I am not saying that II can’t be improved or that the discussion here doesn’t have value. I am just saying we are getting derailed if we’re discussing using II for long-term/cold/high value staking or storage.
2 Likes
I really appreciate your clarification @timo. Maybe this is the key of the problem. So, what can one do now if one already staked one’s ICP using one’s Internet Identity. I look forward for using Hardware Ledger, but things seem stuck for its Integration. Is it possible to use quill retroactively, and desynchronize my neurons and my Internet Identity ?
Still, it would mean that a non developper doesn’t have a way to stake securely his ICP. In this case, every non developer stakers would have to surrender to not stake or to risk everything, and this would mean that ICP is not for mass adoption or at least for investors adoption. It would be reserved only to investors who would be also developers. If this is, quite bad situation for ICP’s future so…
2 Likes
For improving the II we could discuss:
-
creating two levels of authentication methods, higher level and lower level, and you need to be logged in with a higher level method in order to remove (i.e. delete) a lower level method. But
a) using the higher level must be optional,
b) the user must be able to choose which method to put on the higher level (for some it is the phrase, for others a Yubikey, etc.)
c) it must be possible to put more than one method to the higher level if the user wants that.
This is just like an admin vs user account in an OS. You can create multiple accounts of either type. -
Introducing threshold. So that for example you need to call “delete” with two out of three authentication methods in order to be able to delete an authentication method.
6 Likes
No, if you have staked with II then you can’t change that. Maybe a future upgrade to the NNS will allow changing the controller of neurons. If that happened then you could change it. But I don’t know when or if that will ever happen. The reason that the neuron controller cannot be changed is so that neurons can’t be sold. That’s something the community has to decide if it wants to continue to prevent the sale of neurons and how. If someone comes up with mechanisms that allow to change the controller of a neuron while at the same time preventing a sale then changing the controller can be allowed.
Anyway, to your question what to do now in the short term. If you already have staked a significant amount with II then I would suggest the following:
Take a dedicated laptop for managing your neurons. Here, “managing” means changing dissolve delays, dissolving, disbursing, spawning. Those actions should happen infrequently. “Managing” does not mean voting. For voting you can configure a hotkey and you can vote from your everyday phone/laptop. The dedicated laptop can be old. If it is so old that it does not have a biometric sensor then you can use a Yubikey with it or you can type in the recovery phrase every time you need to manage your neurons. What is important is that you don’t use the dedicated laptop for anything else than opening a browser and going to nns.ic0.app. That way you can get almost as secure as with quill or a hardware wallet. The more you restrict the laptop the better. The security is gradual. You could for example, configure a dedicated Wifi network in your router and let that dedicated laptop be the only device connected to it, so that your dedicated laptop and your everyday devices don’t share the same Wifi, etc.
This unfortunately also means to create a second II for every day use. Don’t log in with the II that control the neurons on any other devices than your dedicated laptop.
You can configure your second II for every day use as the hotkey of the neurons. That way you can vote and monitor from your everyday devices.
In the medium term, you should request the feature to allow hotkeys for the “merge maturity” action. I understand that is the main reason why people want to manage their neurons frequently. Some people are merging daily. The easiest answer to that would be to allow hotkeys to trigger the merging. Or, alternatively, an auto-merge feature that you only have to enable once would also work. I think auto-merge is already being worked on.
In the medium term you can also push for improvements to the II that you started with. But please understand that over the dedicated laptop it will be a relatively small security gain.
4 Likes