How is Internet Computer protected from hacker sending arbitrary messages from a user identity to arbitrary canisters, after a user having been logged with Internet Identity?
For example, in Ethereum MetaMask window is opened and the user is asked for confirmation.
This thread answers positively my question on whether it is protected from hackers, but it says vague “The way it does it is by giving you a different identity for each application that you visit.” where I don’t understand what it means an “application”. How application boundaries are defined/determined?
In the broadest sense - if someone has your private key, you are hacked and the Internet Computer cannot protect you.
Some wallets in the IC ecosystem include extensions that can prompt users for a confirmation. Plug wallet, NFID, AstroX and others take this approach.
Delegated identities, which are used by Internet Identity and NFID, can include scopes, indicating which canisters they are allowed to make calls to, as a type of protection against making calls to arbitrary canisters with a given identity, but they will not prompt users for confirmation.
Other programmatically created identities may not offer any protections.
There are many ways to generate a valid signature for the Internet Computer. It is important to consider the security risks of your use case carefully when deciding on which authentication strategy provides the best balance of user experience and security for your own application
Why when I use login in into NFID in my application, I see nothing about scopes? How to add scopes?
And, most importantly, you didn’t answer my main question: “The way it does it is by giving you a different identity for each application that you visit.” where I don’t understand what it means an “application”. How application boundaries are defined/determined?
In casual parlance, applications or ‘dapps’ on the Internet Computer typically consist of a smart contract combined with a user interface of some kind. That interface could be a native application, a website, a command-line interface, or some similar workflow.
Applications will have boundaries that are determined by the properties of their respective computing platform. Websites have domains, security policies, browser storage interfaces and so on. Native apps will have their own strategies for persisting and securing user data. The strategies that you need to take will depend on what your application does and what technologies are used
What property is used to secure boundaries of a DFX-deployed frontend canister?
I mean: How II and NFID (or rather identities “installed” by them) determine what is inside or outside the boundaries of a DFX-deployed frontend canister?
There is an edge case around being able to resolve the same principal across multiple origins, but otherwise II and NFID are not concerned with whether your website is hosted on an asset canister
You’re inventing rules that don’t exist, so this is probably as far as I can help.
Any identity can make a call to any canister. It is up to the canister whether it accepts the call
If you access a canister from a third party dapp, the identity that is available in that context will be used while making the call. Again, it is up to the canister’s logic whether it will accept that call
Canisters are not grouped unless they have specific logic to relate to each other. The only system-level access control for the IC is
signatures are validated
calls signed with Delegation Chains can be scoped to certain canisters
the principal of the caller is provided with every call
canisters have controllers
Everything else is changeable and is up to your own discretion. If you are interested in best practices, or have a particular use case you’re looking for advice on, that’s a different matter
Do I understand correctly that because the identity is different for two dapps, the principal (({caller}) value) will be different despite the user is the same?
I am trying to understand what is “that context” that you mention. How the identification system decides which identity to use for which call? Why will it use one identity for call to one canister and another one for another canister?
Well, I will still reformulate my question in a different way:
What (for example: the domain used to make the SSL call, subnet the canister locate in, etc.) prevents my dapp to call a third-party canister with the same identity as one used to call canisters of my dapp (and thus break the security)?
Sorry, I made an error in my previous reply. Here is it’s rewrite:
What (for example: the domain used to make the SSL call, subnet the canister located in, etc.) prevents my dapp to call a third-party canister with the same identity as the one used to call canisters of the other dapp (and thus break the security)?
If there is no such constraint, my dapp can “sign” to a payment canister as the same identity as the identity used by the current user to make his payments and make arbitrary payments (e.g., send all funds to me, the hacker) on behalf of the user without asking user’s confirmation, can’t it?
If you want use an identity provider that does require user confirmation, you could use https://plugwallet.ooo/, https://infinitywallet.io/, or https://astrox.me/. It’s also possible to use Metamask etc although we admittedly could make that easier with some library changes.
Again, it comes down to the needs of your application. Not all use cases require the same level of security as transferring ownership of tokens. A social media application that launches a popup for every “like” or comment would be completely unusable
Does anything prevent my dapp to call a user to sign in, and then transfer all his ckBTC tokens to my wallet by using the same identity that is used by that user when he/she logins to NNS? From your words it sounds that I can do this.
What would it even mean for “your dapp” to “call a user to sign in” to nns.ic0.app? Like, you could just tell someone to do that, and if they do then they’re a fool.
Your app cannot resolve the same principal as II because of all of the technology that makes that delegation possible and secure, unless you are able to somehow capture the https://nns.ic0.app domain. I’m signing off for the day, but please read the documentation
In my quick take, if you’re into coding, the simplest way to understand how II and authentication work to safeguard against hacks is to give it a shot yourself. Try creating a ‘application’ canister that attempts to grab your ckBTC using your hacking strategy scenarios. It’s like testing the waters to see how secure things really are.
Thanks for supporting me anyway. I finally found the answer:
users have separate identities (or “pseudonyms”) per client application (more precisely, per client application frontend “hostname”
^^ The Internet Identity Specification
I should have guessed this, but I was fooled by the fact that my dapp works both on localhost:8000 (the frontend canister) and localhost:8080 (plain WebPack). I didn’t guess that these have two different identities. My wrong assumption that these have the same identity made me to make all the above wrong assumptions. Sorry.
