Important Community Update on ic0.app domain being flagged by an anti-spam blocklist

[Roman]

On my side, FIDO (same device) works on the old and the new link. I even removed the recovery phrase.

[rckprtr]

Would be cool to see what steps you guys took to appeal it. This has happened to DSCVR a couple times and we just filled out all the AV/ISP appeal forms and it went away.

Its been awhile since I’ve last noticed it so maybe once they get you in the registry they stop happening. Lots of websites use sub-domains for their apps so I imagine they are a bit understanding.

[Mr_Burkes]

Why is II domain-dependent? Can’t the IC sign messages that prove authenticity? Can’t this signature be done for authorization credentials?

[diegop]

Please note that I have updated the main forum post (based on input from Crypto team):

@diegop

UPDATE: Now that ic0.app has been removed from the block list, we recommend that users wait to migrate their devices until we complete work on the migration path. In case of an emergency, make sure that you have a usable recovery phrase following the instructions listed above.

[bjoern]

@lastmjs

I thinks it’s important to reflect on the design of II. It seems almost unbelievable to me that the design allows a user to possibly lose their II if a domain name disappears.

The web authentication standard specifies that the credentials are bound to the origin, meaning (amongst others) the domain name. So as long as we are in the realm of web authentication (which allows us to combine a pretty good level of security with a pretty good level of usability), there is not much we can fundamentally do about this. That doesn’t mean that things did not go wrong or we shouldn’t change things, it just limits our options.

I think this should be scrutinized and mitigated somehow, quite unnerving. A self-sovereign identity should not be inextricably linked to a centralized naming service.

Let’s have a closer look at the details.

• The use of ic0.app: The decision to serve Internet Identity under identity.ic0.app was, in retrospect, wrong. I don’t think there’s much more to say about this now, other than that we already had planned migrating to identity.internetcomputer.org before this incident; the incident simply began before we had the nice UI flow prepared. This work will continue, and we will migrate to the new domain regardless. As the content under internetcomputer.org is controlled much stricter than under ic0.app, the domain is much less likely to suffer from such an incident.
• Different ways of blocking ic0.app: There are different possible levels of impact for the domain name, and the one we saw is actually the most benign. It is relatively easy to circumvent on the client side with a moderate level of tech savviness (use a different DNS resolver like 8.8.8.8 or 1.1.1.1, use a VPN). A worse level would be Google (the owner of .app) completely blocking the domain. In that case, users would have to change domain resolution (e.g. edit /etc/hosts, or set the DNS resolver to one that DFINITY or the community could provide, which would still resolve ic0.app) and accept a certificate that is not issued by a generally trusted CA, as Let’s Encrypt, now any other CA, would not extend our certificates for ic0.app any longer. It seems unlikely that the latter would apply to internetcomputer.org.
• Recovery phrases: As you pointed out in a different message, recovery phrases as implemented in Internet Identity today have serious security drawbacks. In contrast to the web authentication keys, they are not held on a specific secure chip but simply in browser memory, which makes them more prone to attacks.

So where does that leave us and where should we go? In principle I see three avenues:

1. Make the use of web authentication more reliable: This is the path we are already taking with identity.internetcomputer.org. Additional steps could be extending the IC to act as a DNS resolver or providing web extensions for browsers.
2. Provide additional recovery options – recovery phrases have security drawbacks and recovery devices still suffer from the domain name problem. Tech-savvy users can already use dfx or ic-repl to effectively register an additional “device,” possibly even with a key stored on an air-gapped device. We could have a phone app that works in exactly the same way as the recovery phrase, but without the use of browsers?
3. Remind everyone to use hardware wallets for managing (at least larger amounts of) tokens and neurons. Internet Identity is great for authenticating toward dapps, but it still fundamentally relies on the security of the browser (which is the still piece of software most likely to be affected by zero days), and so fundamentally that isn’t a good way of managing things of significant value.

[bjoern]

@Fulco

I’m not that knowledgeable about webauthn but do credentials still work when you switch to a custom dns server?

Then the foundation could potentially setup a custom dns server that resolves ic0.app so that there is always a way to recover your identity.

Yes, the credentials would still work with a custom DNS resolver, and this would be one possibility for recovery. It works well on Desktop, but to the best of my knowledge isn’t really an option for mobiles on a cellular network.

[bjoern]

The domain dependency of II comes from web authentication – the mechanism in the browser that allows us to access keys stored in the secure chips of the devices. That policy is enforced by the browser, there’s nothing that II can do to circumvent it.

[lastmjs]

@bjoern

Remind everyone to use hardware wallets for managing (at least larger amounts of) tokens and neurons. Internet Identity is great for authenticating toward dapps, but it still fundamentally relies on the security of the browser (which is the still piece of software most likely to be affected by zero days), and so fundamentally that isn’t a good way of managing things of significant value.

I wish I had known/understood this back in 2021. I feel like the marketing/eduction around II vs hardware wallets wasn’t really present, or at least I missed it. Seems to me that most of the lay people in the community believe (believed?) II to be extremely secure. It’s only after digging in that we discover these flaws.

So a concrete suggestion is to fix the education/marketing of II, or increase its security. How many people have locked up a lot of ICP on the NNS using II? Probably a lot of people. And the unfortunate thing is that there is currently no way to change that choice AFAIK.

[lastmjs]

@bjoern

Different ways of blocking ic0.app: There are different possible levels of impact for the domain name, and the one we saw is actually the most benign. It is relatively easy to circumvent on the client side with a moderate level of tech savviness (use a different DNS resolver like 8.8.8.8 or 1.1.1.1, use a VPN). A worse level would be Google (the owner of .app) completely blocking the domain. In that case, users would have to change domain resolution (e.g. edit /etc/hosts, or set the DNS resolver to one that DFINITY or the community could provide, which would still resolve ic0.app) and accept a certificate that is not issued by a generally trusted CA, as Let’s Encrypt, now any other CA, would not extend our certificates for ic0.app any longer. It seems unlikely that the latter would apply to internetcomputer.org.

Seems in the worst case a solution could still be provided to recover the identities by setting up custom DNS/certificates. That’s at least better than having no recourse whatsoever.

[Denis]

@bjoern

As you pointed out in a different message, recovery phrases as implemented in Internet Identity today have serious security drawbacks. In contrast to the web authentication keys, they are not held on a specific secure chip but simply in browser memory, which makes them more prone to attacks.

Does this mean all recovery phrases are vulnerable to being hacked, and everybody staking on Internet Identity could lose their coins if a hack successfully harvests recovery phrases?

[diegop]

@Denis

Does this mean all recovery phrases are vulnerable to being hacked

I believe he means that since the recovery phrase is shown on the browser when you generate it, this automatically makes the browser aware of the recovery phrase during that time, which in in theory makes it a danger, even if the recovery phrase is there for only a few minutes or seconds. Please note this is the case for ALL web-based products that show the users a seed phrase (either the extension or browser could in theory be compromised).

I would assume that if such a browser hack existed, it would have been exploited much earlier in other wallets or extensions, but this does not rule out that it may yet present itself.

Meanwhile, the FIDO/WebAuthn authentication never show the private keys to the browser so the browser is unaware.

[JaMarco]

@lastmjs

So a concrete suggestion is to fix the education/marketing of II, or increase its security. How many people have locked up a lot of ICP on the NNS using II? Probably a lot of people. And the unfortunate thing is that there is currently no way to change that choice AFAIK.

So you can’t switch to using a hardware wallet after first using II?

[blabagastered]

@bjoern

Internet Identity is great for authenticating toward dapps, but it still fundamentally relies on the security of the browser (which is the still piece of software most likely to be affected by zero days), and so fundamentally that isn’t a good way of managing things of significant value.

Is there a secure way to authenticate into dapps (that’s “a good way of managing things of significant value”)?

[bjoern]

@lastmjs

I wish I had known/understood this back in 2021. I feel like the marketing/eduction around II vs hardware wallets wasn’t really present, or at least I missed it. Seems to me that most of the lay people in the community believe (believed?) II to be extremely secure. It’s only after digging in that we discover these flaws.

Let me clarify. Authentication with II is still fundamentally more secure than browser-based wallets like Metamask or Plug, because the cryptographic key resides in a secure hardware chip and outside of the realm of the browser or even the computer’s main memory. It is, however, also fundamentally less secure than a hardware wallet, since the hardware wallet will allow you to inspect the transaction. With web authentication, you as a user must be involved (e.g. fingerprint or face scan), but you don’t see the transaction details.

Let me put out some numbers. Here are values that I would feel comfortable with managing in different ways (these are based on my personal risk profile, everyone will have different limits):

• Browser wallet (e.g. Metamask/Plug) on my own general-purpose devices: $100s, for short time maybe $1’000s.
• Internet Identity on my own general-purpose devices: $1’000s, for short time maybe $10’000s.
• Browser wallet or Internet Identity on a “clean” device that I only use for one specific application that I personally trust, and where the front-end is decentralized (e.g. nns.internetcomputer.org) and that I never connect to public networks: $10’000s and maybe a bit more if I am paranoid about keeping the device clean.
• Hardware wallet (which I never connect to a device I don’t own): $100’000s.
• Custom cold-storage/air-gap setup: Anything beyond.

So I did not want to suggest that Internet Identity wasn’t secure – quite to the contrary! I personally think it has the best trade-off between security and usability for day-to-day use. I just want to encourage the use of “non-day-to-day” methods for cases for large amounts of tokens.

[bjoern]

@Denis

Does this mean all recovery phrases are vulnerable to being hacked, and everybody staking on Internet Identity could lose their coins if a hack successfully harvests recovery phrases?

Yes, in exactly the same way as that hack would reveal the private key in your Metamask/Plug/… browser wallet. There is an important difference, though: The recovery phrase is created once and then deleted from your computer’s memory, you probably don’t use it until you lose access to your identity anchor. The browser wallet will have the cryptographic key in memory every time you make transactions. So in reality, the attack surface for the Internet Identity recovery phrase is still a lot smaller than the one for typical browser-based wallets.

[bjoern]

@JaMarco

So you can’t switch to using a hardware wallet after first using II?

The NNS disallows the change of the controller for an existing neuron. This is not specific to II, it generally means you cannot change the means of controlling your neurons.

[bjoern]

@blabagastered

Is there a secure way to authenticate into dapps (that’s “a good way of managing things of significant value”)?

No, at least there is not a general solution. I think there is a fundamental contradiction between the two: I want to be able to use my day-to-day dapps in my browser, without explicitly authorizing every transaction from a separate, secure device. For managing things of significant value, I would not trust the browser, and I would want to authorize every transaction from a separate, secure device. I think applications like DeFi should have support for things such as a hardware wallet.

[blabagastered]

To be sure I understand correctly:

(a) If you create an Internet Identity anchor, then add a Ledger Nano device via FIDO, then delete your biometric device so that the only remaining device is the Ledger Nano, and you don’t ever create an II recovery phrase (since it is displayed and generated by your insecure, internet-connected device), is that secure / comparably secure to eg using a Ledger Nano via Metamask on Ethereum, or is it still insecure due to it still using using Internet Identity as the base layer?

(b) If you instead do Ledger Nano via Metamask via NFID (it still uses II in the background I think) to authenticate into a dapp, and again do not “trust” any device and only use it with the Ledger Nano, is that still insecure for significant value?

@bjoern

applications like DeFi should have support for things such as a hardware wallet

(c) if (a) and (b), which use II, are not secure, how does a dev add support for a hardware wallet into their dapp?

[bjoern]

@blabagastered

(a) If you create an Internet Identity anchor, then add a Ledger Nano device via FIDO, then delete your biometric device so that the only remaining device is the Ledger Nano, and you don’t ever create an II recovery phrase (since it is displayed and generated by your insecure, internet-connected device), is that secure / comparably secure to eg using a Ledger Nano via Metamask on Ethereum, or is it still insecure due to it still using using Internet Identity as the base layer?

The FIDO app on the Ledger Nano is a great recovery mechanism for Internet Identity, but mostly because you can have a backup of the keys (which you cannot have with most other FIDO devices like a Yubikey). The security properties are not fundamentally different from other web authentication devices that support user verification, because you cannot actually validate the contents of transactions.

(c) if (a) and (b), which use II, are not secure, how does a dev add support for a hardware wallet into their dapp?

The ICP app on the Ledger Nano that you can install today supports only a fixed set of transactions for the governance and ICP ledger canisters. The next version, which is in review with Ledger literally at this very moment, adds more generic support for some SNS and ICRC-1 transactions (as per this PR).

We are currently designing a scheme that allows any canister on the Internet Computer to use the ICP hardware wallet app for securely displaying and signing transactions, and that would work as follows:

• The canister developer specifies for each pair of (canister id, method name) a schema for rendering the parameters. That would likely be a transaction name and a structure that specifies for each field of the Candid argument whether it should be displayed and the title that should be used. (We need to devise a format for this, this actually is the main open design task.)
• The canister then signs said schema with the IC’s threshold ECDSA signature method.
• The dapp front end sends the unsigned transaction along with the signed schema to the hardware wallet.
• The hardware wallet derives the canister’s ECDSA public key from the IC’s ECDSA root public key and the canister id, and verifies the signature on the schema. It then uses the schema to display the transaction to the user, and signs the transaction when the user approves.

How does that sound?

[blabagastered]

@bjoern

How does that sound?

I hear two sounds. One general, one particular.

The particular one, without attempting a detailed evaluation of the proposed solution, is that I worry about the timing (ie when might this be available for use in production, especially considering adopting this approach to security may require re-modelling an application’s flow, data structure, architecture, and extra work aside, it can really only begin once this is totally finished), and also worry about the reliance on threshold signing as currently implemented (see for example from 48:00 here https://twitter.com/i/spaces/1gqxvyREnwlJB?s=20 together with (Discord) ), which sort of steps on the general:

The general is that, without knowing the foundation’s work from within or the core protocol in any detail, my impression is that the number, breadth and depth of security vulnerabilities in the system, understood as broadly as possible, ie in the only way in which it makes sense to understand it in production, in “the real world”, appears to be large enough that perhaps all work should be suspended, on every sphere of the foundation’s technical efforts, until all major security concerns have been addressed and fixed to a point such that a dapp deployed on the IC, with its then existing implementation (not a future imagined one) is comparably secure to what is achieved by competing systems today.

It may sound radical or alarmist, and I would be glad if it were so, but I can’t help but conclude that without security, there can be no public blockchain, or certainly no responsible use of it at anything remotely like the scale of the IC vision.

I say this in the most constructive tone possible: yes, I am alarmed, but if the will (and perhaps courage) to really look at security is there, and to tackle it whatever the cost, and I’d expect it to be a very uncomfortable exercise, I have a feeling the foundation, with its great technical resources, is still not beyond a point of no return where such fixing becomes effectively incompatible with the IC gaining traction within a time window such that its long term survival and thriving is achieved.