If someone is using fido, and needs to add a device to the new domain, can they add the recovery phrase, utilise it to recover account on the new domain, add required devices, then delete the recovery phrase and add Fido as a key again ?
Tldr; how to secure account using only fido or ensure fido remains only access to account
Preemptive damage control I get it, still felt very reluctant doing this seeing as the current method and implementation leaves us vulnerable to security risksā¦
And this 100%:
Hoping this countermeasure is a smooth process as to avoid possible fallout!
If someone is using fido, and needs to add a device to the new domain, can they add the recovery phrase, utilise it to recover account on the new domain, add required devices, then delete the recovery phrase and add Fido as a key again ?
Tldr; how to secure account using only fido or ensure fido remains only access to account
Yes, that works!
I recommend using a different name when adding the new device so you can better distinguish the two domains.
I use Ledger as Fido. Thereās no need to touch the Seed Phrase( so far as you can log into ic0.app) to simply add the Fido device to the internetcomputer.org domain. Follow the instructions on top by diego
Imo:
(a) you should have more than one device to login.
From OP: Please note: You will not be able to recover your account with a FIDO device, so you must create a recovery phrase if you want to ensure your account is safe.
This means we are unable to use Fido to recover our accounts on the new link, unless we set up Fido on the new link utilising the methods above, I think⦠Iām personally waiting for a little more clarity before moving ahead re Fido
Iād also like to know how many times we are expected to have to do this, is a permanent solution being worked on and is this likely to happen to the new link ( it being blocked too )
@Zane is definitely making a point. Fully agree. I had not created a recovery phrase, because I wanted to avoid some risk. Dfinity itself recommended FIDO rather than the recovery phrase in an article called : " Is a recovery phrase as safe as a recovery FIDO device ?". Spoiler : the answer is ānoā of course.
Clearly, we canāt afford such an idiosyncrasy. Particularly since we aim to become a world computer, in which one the II appears as the trusty angular stone to the average user.
So the recovery phrase must be used right now of course, because there is some potential danger, but the best is to eventually find a way to rely exclusively on a seed air gapingly created like Ledger HW make everybody able to do.
A lot of people will create the recovery just to make the transition between the 2 domains, but look forward to deleting it as soon as possible. Let us make them able to do this quickly.
I want to provide some context since this is his first time on the developer forum:
@jwendling is the Team Lead of InfraSec at DFINITY, and person working closely on this case (and with spamhaus). He is one of the experts in this matter.
(I probably should have mentioned that in the original post)
Dominic Williams should consider suing Spamhaus as they have already tried to sue meta and suing spamhaus would be a global win for defi and perhaps set precedent that we can fight back
Hard to be exact and say a definite āwhyā, but Spamhaus communicated the following intent:
ā Whether or not ic0.app is compromised is not the issue, the issue is that it enables this sort of massively automated malice and hiding the actual destination.ā
I am not sure about what exactly this is what they consider automated malice. Is a load balancer also automated malice because it hides the true destination?
I am sure that @jwendling will be able to work this out with spamhaus.
However if it doesnāt get worked out, we will need to think about alternatives because the same logic can be applied to any domain.
However if it doesnāt get worked out, we will need to think about alternatives because the same logic can be applied to any domain.
Yes, this is a risk that every domain is faced with. But through the Custom Domain feature, canisters can have their own domain, which means we will have more domains in total, and the likelihood of services like NNS being blocked by such blocklists decreases greatly.
While i donāt have access to the whole context and content response, the quote by Diego
leaves me a little jittery. If i read in between the lines (more than i probably should ) , it seems to suggest that the author thinks that something nefarious is going on behind the scenes (i.e. use word malice and phrase hiding the actual destination). Without malice, when we host even a backend with update, who is serving the response, is āhiddenā by design; in the sense that we have many replicas getting the update call.
This is why, imo, we should close this asap with Spamhaus; because it will, otherwise, trigger a cascading impact on dns servers. The fact that nns is now on internetcomputer.org is of no consolation ; because logically, they will block that as well.
Of course not having all the context may mean that i am being too paranoid. But, as i have mentioned before,only the paranoid survive in this game. More than happy to be proven wrong in the previous two paragraphs.
Do you think one possible solution is to have a domain reserved for core services and apps? Perhaps an NNS vote could be required to have a site on that core services domain, making it a community whitelisted IC. That way, we avoid having to censor while also sealing off any nonsense that goes on in the wider network from systemically important services. Because making a malicious website or app is extremely easy. Now that this issue is public, people will do it just to sabotage the IC.
Why does Fido not work at all if set up accounts on both links you can only have access to one link using Fido recovery max
Patch needed
I have set up devices on both links, and Fido now only works on the new link