Security in Internet Identity Delegation: how to limit scope of malicious app?

internet-identity
1

In this talk about Internet Identity it is said that

“we scope each delegation to contain only those canisters necessary to run the given front-end applications.”

But what if the front end application allows eg transferring all your funds with eg hidden UI? How do you ensure that you’re not giving too much delegation power to a random application?

Unless it means just the front end without any power to call any back end functions, but when I’ve used a couple of apps via Internet Identity, I don’t get asked to sign again when I trigger backend changes.

Is there a solution for this or do you just have to be careful about what IDs you use to authenticate on each application, meaning only authenticating with funded IDs on sites you trust?

4 Likes
2

Hi @blabagastered

Good question! :slightly_smiling_face:

Internet Identity makes sure that a malicious app is constrained to it’s own scope in terms of damage it can do. The way it does it is by giving you a different identity for each application that you visit.

Example:
Imagine two applications both interacting with the ledger canister, A and B.

  • Both applications have an account for your principal.
  • On application A, you are known as Principal_A, on application B as Principal_B.
  • The ledger manages accounts / funds for each principal.
  • The ledger does not know that Principal_A and Principal_B are derived from the same Identity Anchor. For the ledger these are just 2 different accounts.

So if application B would turn out to be malicious, it could still not steal the funds tied to application A from your ledger, because from the point of view of the ledger these funds belong to a totally different user.

This very strict isolation is very secure, but has also drawbacks: there are many scenarios, where you want to give some application access to assets / resources that you own under a different principal (i.e. if you want to share data managed by one service to be consumed by another).
We are actively working on protocols to facilitate such interactions while maintaining the high security standards that we have. These flows will then prompt you for additional consent to specifically authorize interactions between different services.

If you are interested in the topic and want to help develop the solutions, please join the identity & authentication working group. The next session is today.

7 Likes
3

Thank you. It makes sense.

I’d be honoured to participate in the working group if I come across something I could contribute. I’ll dive deeper into Internet Identity soon to integrate it to a security-minded project and I don’t rule out turning up then.

2 Likes
4

When is the next meeting?

5

Hi @blabagastered

The next meeting is on January 10. See the meeting calendar linked in this post (below all the different working groups is a shared calendar link).

1 Like