Internet Identity V2

Developers internet-identity
62

I don’t want to sound rude, but if what’s on try.id.ai is how Internet Identity will work in production, then Dfinity just introduced a massive security risk.

I created a new identity named “jhon” and used a YubiKey to register. All of this was done in private/incognito mode on my iPhone. After creating the identity, I closed the tab — meaning all local storage was cleared.

Later, I went back to the site, clicked:
• “Try the new sign-in experience”
• “Continue with passkey”
• “Use existing passkey”
• Selected “security key”

I plugged in the same YubiKey and… that’s it. I was in. No anchor ID, no additional step, nothing. Just physical access to the key granted full access to everything: my identity, my potential net worth, private data, etc.

Let’s consider a very realistic scenario: someone loses their YubiKey, and now that II is going mainstream, the attacker just plugs it in and gets full access. No need to know the anchor number or any context. That anchor prompt in v1 was actually a very important barrier — even if technically unnecessary, it served a critical security function in the real world.

Right now, this feels less secure than a regular email login, because at least with email/password, the attacker needs to know something. With this, possession = total access.

Before, the YubiKey was like a key that could open a safe — but only if you knew where the safe was (the anchor ID). Now, it’s like the key not only opens the safe, but also magically finds it for you, no matter where it is. Just plug it in, and boom — full access.

@bjoernek @bjoern @Jan @dominicwilliams guys you are aware of this?

1 Like
63

I still can’t understand who asked to them to do this thing, I
Mean they could make it simple, no remember the anchor ID, but i was imagining that the “nickname” your provided was in some way attached to the anchor id on the database, and then you should be asked for this nickname at least everytime you login in, and then this nickname because is linked to the anchor id is someway looking if the yubikey private key matches the anchor id - nickname info. This could not be technically necessary as the developer said before, but it’s very necessary on the real world, now if you lost the yubikey all whoever finds it on the street is go to NNS, sign in with security key, introduce yubikey, and he’s inside. I can’t believe Dfinity is doing this amateur thing

1 Like
64

The thing is this radical
Change introduces security vulnerabilities, maybe not on the technical side as the developer has mentioned, but it does on the practical use cases, if i lost my yubikey, or someone knows i have it, just requires going to NNS url, internet identity url, insert the yubikey and there you go, the person is inside all your personal data, networth everything, I can’t honestly believe dfinity isn’t aware of this scenario that is 100% possible

65

Why are you trying to justify something that clearly affects security? Doesn’t require to much technical knowledge to understand that for a real scenario is way simpler to access to my any NNS with just inserting the yubikey, instead of knowing the anchor id plus having possession of the yubikey.

Doesn’t matter if today i lose my yubikey and someone with technical expertise can “loop
Over all possible II” it will take days to find it, it will require a planned attack against me as a person, not a regular robber.

The scenario i
Provide is real, is just lose the yubikey on the street, ICP is mainstream, anyone who sees a yubikey will try to use it on the NNS, internet identity website etc, and they will access without friction to someone’s data, money, etc.

Who told dfinity this was a good idea honestly? I hold thousands locked on 8 year neurons on the NNS, I can’t even add a ledger, and now this II v2 juat makes things worse, Dfiniry what are you doing guys?

66

So an attacker will need to introduce the “nickname” and the yubikey?

Or just with the yubikey they will get access without knowing anything else?

67

Yeah, hoping Dfinity team can consider it, 5 digit, 6 digit, 7 digit, even 8,9,10 digit number is not hard to remember, just remember several times. I think anchor number is cool design, anyway, i will always using my 5 digit anchor.

1 Like
68

I think the whole issue of this is Dfinity forced to use internet identity on critical apps like NNS that holds value locked in neurons, and this whole design its rigid that they can’t be flexible in terms of achieving a better and simpler UX for the average user.

So because internet identity is implemented at protocol level, and it’s the only way to log in to the NNS and hold your assets there, they now have to compromise security over user experience because they found that the average user have to remember 6 digits and this creates a bit of friction..

I think they have to find the way to let users log in with anchor id and yubikey.

And others use just the yubikey without any other numbers or nicknames. If they want.

3 Likes
70

First of all, I’d like to thank the DFINITY team. Let me share my thoughts. Personally, I really like numbers. Of course, the fewer the numbers, the better. I think the five-digit number II in v1 is great. For instance, mobile phones have numbers, car license plates have numbers, and even Google accounts have numbers. I think having a number is also a very good thing. I think the upgrade of V2 is quite good, but it would be even better if the number of v1 could be retained. I’m used to logging in to the ICP application with my five-digit ii number. I think getting more people involved in ICP, the identity verification should not be too complicated, and security should come first. I think this is the most important thing.

72

As for the issue of losing my passkey, I would still have enough time and awareness to delete that passkey before whoever found it could loop through all the identity numbers and try them.
But in version 2, I’m afraid I wouldn’t have enough time to delete the passkey anymore, they could already access everything and take all the assets before I even have a chance to react.

You may not consider this a security issue, but for me, time is a crucial factor in security. I see this upgrade as a trade-off between security and UX (user convenience), but then users will end up complaining about security again when something goes wrong. When asset loss occurs, I don’t think users will have any praise, no matter how good the user experience may be.

As more people become aware of ICP and the NNS, it’s also the time when users need to be more vigilant in protecting their physical key, equivalent to a seed phrase, and potentially even harder to secure. In the future, as asset values increase, targeted attacks will likely become even more common than accidental passkey loss.

1 Like
73

This should be something optional, Dfinity team seams that has been updated/ changed, this people seem to be doing everything bad in my opinion, no one ask to them to remove the second layer of security, if they wanted to make it simpler then remove the 6-7 digit number but always ask to the end user the nickname he created, example if I choose “jhon” always ask this nickname in order to log in successfully, if i put “carlos” and insert the yubikey attached to “jhon” the access must be declined.

What i would do if this is done like that is will put as “nickname” the same 7 digit of my anchor ID. So now my nickname is my anchor id.

1 Like
75

if what’s on try.id.ai is how Internet Identity will work in production, then you guys just introduced a massive security risk.. it just requires a bit of thinking and you will find why.

I created a new identity named “jhon” and used a YubiKey to register. All of this was done in private/incognito mode on my iPhone. After creating the identity, I closed the tab — meaning all local storage was cleared.

Later, I went back to the site, clicked:
• “Try the new sign-in experience”
• “Continue with passkey”
• “Use existing passkey”
• Selected “security key”

I plugged in the same YubiKey and… that’s it. I was in. No anchor ID, no additional step, nothing. Just physical access to the key granted full access to everything: my identity, my potential net worth, private data, etc.

Let’s consider a very realistic scenario: someone loses their YubiKey, and now that II is going mainstream, the attacker just plugs it in and gets full access. No need to know the anchor number or any context. That anchor prompt in v1 was actually a very important barrier — even if technically unnecessary, it served a critical security function in the real world.

Right now, this feels less secure than a regular email login, because at least with email/password, the attacker needs to know something. With this, possession = total access.

Before, the YubiKey was like a key that could open a safe — but only if you knew where the safe was (the anchor ID). Now, it’s like the key not only opens the safe, but also magically finds it for you, no matter where it is. Just plug it in, and boom — full access.

2 Likes
76

Why would you need a Yubikey for each II?

1 Like
77

This
Option is something that will be available on II v2

Or is something that currently is supposed to be working? I say it because i have a pin on my yubikey 5ci and I tried on the V2 II, and the system asked me to introduce the PIN, but on the II v1 it never had asked me to introduce that PIN. So
I guess this is something unique that will be implemented on the II V2 and at the moment is not available on the II V1 ?

78

There is a video in this link shows migration existing users to new ii v2, seems mandate to change anchor number to nickname, not sure if it is official or not.

79

In crypto, the norm is for users to remember (write down) 10-20 word seed phrases, but a 7/8/9/10 digit number is to far..?

We can all remember our phone numbers, right..?

I appreciate the work the DFINITY Team does, but I hope this migration is optional - especially given the level of pushback the community has already shown.

2 Likes
80

I get where you’re coming from, but honestly this thread feels like a pretty small sample of the actual community. I’ve seen way more excitement about II v2 on Twitter and other platforms than resistance.

The security concern is valid. But here’s the thing - @sea-snake already mentioned that v2 supports YubiKeys with PINs. If you’re actually worried about losing your key, just use one with a PIN. Someone finds it on the street? They still can’t do anything without your PIN.

The seed phrase comparison doesn’t really work. Sure we memorize those, but only because we have to. If there’s a way to make this easier for regular people without sacrificing security, why wouldn’t we want that?

1 Like
81

Hey @GeekFactory

Doesn’t it look like they are trying to make trading anchor harder ?

  • Alternative Logins: Integration with external providers (e.g., Google) ties identities to third-party credentials, which are non-transferable. This further reduces the feasibility of trading identities, as they’re linked to external accounts rather than standalone anchors.
  • Impact on Trading: Trading platforms like idgeek.com rely on the transferability of anchor numbers and their associated recovery phrases. With II V2’s focus on non-transferable passkeys and external logins, trading becomes less practical, as buyers cannot easily assume control of an identity without access to the original authentication method.
1 Like
82

A high quality animated Demo/Tutorial would be great once its ready.

You know, like a bright modern animated tutorial for the mainstream to instantly get it.

83

So if someone has an II 1.0 which only has a ledger as security key he won’t be able to login with the new version for the foreseeable future?

2 Likes
84

An external provider can be unlinked from an internet identity with the remove_openid_credential API call.
Passkeys are never intended to be transferable. idgeek.com removes all passkeys when II is transferred to the contract, and the buyer registers a new passkey when he transfers II from the contract.

3 Likes