SSI does not protect against phishing

[damienbod]

Users authenticating on HTTPS websites using verifiable credentials stored on your wallet are still vulnerable to phishing attacks. This can be improved by using FIDO2 as a second factor to the SSI authentication. The DIDComm communication between agents has strong protection against phishing, not when the user scans a QR code.

Self sovereign identity phishing scenario using HTTPS websites:

• User opens a phishing website in the browser using HTTPS and clicks the fake sign-in
• Phishing service starts a correct SSI sign-in on the real website using HTTPS and gets presented with a QR Code and the start link for a digital wallet to complete.
• Phishing service presents this back on the phishing website to the victim on the phishing website.
• Victim scans the QR Code using the digital wallet and completes the authentication using the agent in the digital wallet, DIDComm etc.
• When the victim completes the sign-in using the out of band digital wallet and agent, the HTTPS website being used by the attacker gets updated with the session of the victim.

This can only be prevented by using the browser client-side origin as part of the flow, signing this and returning this back to the server to be validated, thus preventing this type of phishing attack. This cannot be prevented unless the origin from the client browser is used and validated in the authentication process. The browser client-side origin is not used in the SSI login. At present FIDO2 is the only solution which could solve this.

Here’s the same problem description: Risk Mitigation for Cross Device Flows

Question

Will the E-ID solution protect users against phishing or allow users to have their verifiable credentials stolen in this way?

[fforootd]

At present FIDO2 is the only solution which could solve this.

Just to be picky, client certificates with mTLS are as well 😁 altough the UX of Browsers is not really a great thing, privacy is a tricky problem and the key distribution. However the distribution might be not the biggest issue here. Also the cross device problem also applies to this.

[damienbod]

@romanzoun This does not protect against this type of phishing and it's very easy to implement a phishing website to take advantage of this. Between the wallet and the service is well protected, not when it is initialized. Anywhere a QR Code can be scanned and the auth is completed on a separate device, this problem exists.

[romanzoun]

The QR code is only encoded invitation, which contains URL...Later DID or other identification of the service provider is possible, which you can check in beforehand. Sow you can place a QR code, but after decoding the message behind it, should reveal the identity of the provider and the QR code "owner". The P2P communication is between the holder wallet and the verifier (service provider, not with PC or other local device)

Can you give me a sample for phishing in SSI?

[damienbod]

Hi Roman, this is exactly the problem, this is just an URL… Anywhere a cross device authentication is initialized using a QR Code in the browser, it is subject to phishing attacks and cannot be protected unless using a second phishing secure authentication in the session, for example FIDO2 or mTLS solutions.

In the linked video, there is a SSI phishing example and I described how to do the attack in the issue. If you want to try this yourself, start an SSI authentication which generates a QR code, get a friend to scan your QR code and the friend completes the SSI auth on their mobile wallet and you get the session from the friend in your browser.

This is really a very big problem in SSI which has no known solution at present (or for any cross-device authentication like OAuth device code flow). SSI authentication in this way has no solution for this unless you do not use wallets and cross device initialized from a QR Code. SSI authentication requires some other type of authentication (on the session where the business is) to be safe to use.
Greeting Damien

[romanzoun]

see your point, thanks for the explanation.

Some researches are tackling this for high LoA, see here: https://www.scitepress.org/Papers/2021/105428/105428.pdf
But since moving the responsibility of personal data to the user, you need to increase the security standards for sure...

[damienbod]

Thanks for the link, will read this. Something like FIDO2 integrated in the SSI flows would possibly solve this, but still nothing exists which could be implemented

Greetings Damien