This article explains why cross device authentication has security issues as it is subject to phishing attacks unless further authentication is used in the client. Scanning QR Codes for authentication does not protect against phishing and leaves the users open to having their session stolen.

Phishing

There a many forms of phishing and this is one of the biggest problems the industry needs to solve at present. As a service or software provider, it is not correct for you to expect your clients to be wise enough, not to fall for a phishing attack. We need and must create systems where phishing is not possible. At present the industry provides three solutions to protect against phishing; FIDO2, certificate authentication using PKI and windows for business authentication. FIDO2 will become much more user friendly once the new hardware devices have built in FIDO2 keys and the rollout of passkeys is supported by most of the big service providers.

When using cross device authentication, it is not possible to protect against phishing, or at least we have no known solution for this at present.

Phishing in Self sovereign identity

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 but this does not protect against phishing when started using a QR Code from a separate device.

Self sovereign identity phishing scenario using HTTPS websites:

1. User opens a phishing website in the browser using HTTPS and clicks the fake sign-in
2. Phishing service initializes the authentication using a correct SSI sign-in on the correct website using HTTPS and gets presented with a QR Code (URI link) for a digital wallet to complete.
3. Phishing service presents this back on the phishing website to the victim.
4. Victim scans the QR Code using the digital wallet and completes the authentication using the agent in the digital wallet, DIDComm V2, trusted registry etc.
5. 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.

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

Phishing in cross device

In general, any cross device authentication does not protect against phishing. You need further authentication in the browser/agent client where the session is running.

Comparing apples and oranges

A lot of people pushing these systems compare this form of authentication with single factor password authentication. This type of cross device authentication is much better than password authentication, this is correct, but the industry has already solved this and for any good enterprise systems or secure systems, users can no longer use single password authentication, this is a solved problem. It is just not rolled out to the wider public for the consumer market. Introducing another system will not solve this either.

The cross device application running on the separate device can authenticate its part of the authentication flow correctly and this step in the authentication process is ok and cannot be phished if implemented correctly like for example using Didcomm V2 and trust registries but this does not solve the phishing weakness when starting from a HTTPS website with a QR Code scanned from the original device.

Workarounds

Use a phishing resistant authentication like FIDO2, PKI solution using certificates or Windows for business. Once authenticated, the QR Code can be scanned in a safe way and the cross device authentication can be used for example to verify an identity. This works because you are already inside a secure session and the same session will get updated with the scanned data then.

Links

https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/

Challenges to Self Sovereign Identity

https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-authentication-flows

https://docs.oasis-open.org/esat/sqrap/v1.0/cs01/sqrap-v1.0-cs01.html#_Toc103082217