3D Secure (3DS) is a security protocol that is used to authenticate online credit and debit card transactions. It is an additional layer of security for online card payments, designed to protect merchants and cardholders from fraud. Surprisingly, it is almost a quarter-century old. A bit of background first and i’ll get to the good (bad) stuff.

The protocol was developed by Visa and branded as ‘Verified by Visa’. Other major card networks adopted the protocol as well, including MasterCard (“MasterCard SecureCode”), American Express (“American Express SafeKey”), and JCB (“J/Secure”).

EMVCo, the consortium managing global specifications for secure card transactions, now manages the 3DS specification, and we are now on 3DS 2.2.

It works by the customer’s bank presenting an additional step of authentication (a challenge) during the purchase. This challenge could be presented on the banks website and require a full redirect away from the seller’s site to the bank’s (and back again after), or via an injected iFrame into the seller’s site, or even a popup window (yuk). The most common challenge methods are;

1. One-Time Password (OTP): The bank sends an OTP to the cardholder’s registered mobile number or email.
2. Knowledge-Based Authentication: This might involve asking the cardholder security questions that only they would know the answer to.
3. Biometric Authentication: This can involve fingerprint recognition, facial recognition, or even voice recognition.
4. Mobile App Authentication: In some cases, banks can prompt cardholders to open a mobile banking app to authenticate the transaction. This can involve entering a password, responding to a push notification, or providing biometric data.
5. Hardware Tokens: Banks can provide hardware tokens that generate OTPs. This method is often used for high-value transactions or high-risk customers.

Although I would not be surprised to hear that there are more options.

The merchant is also able to share various data-points about the context of the transaction, to assist the banks’ risk-based approach.

Versions 2 to 2.2 of 3DS added a few bells and whistles… particularly to enrich the user experience for customers on mobile devices, and allow for merchants to share more data-points (~100) to assist in the risk calculations. Support for in-app purchases was also added, alongside better experience on oddball devices like TVs and games consoles.

From a merchant’s point of view 3DS mainly provides a vehicle to reduce their liability in case of fraud, and also help to increase customer trust in online payments. Very admirable stuff.

However, 3DS was considered optional for merchants until 2021, and many merchants were reluctant to build the logic into their websites to support 3DS, and sceptical that the extra friction wouldn’t impact sales. Many merchants toggled 3DS off with their payment providers for this reason.

However, in Europe and the UK we are now mandated to use ‘strong customer authentication‘ (SCA). One impact of SCA is that 3DS support is not something a merchant can disable anymore. A few years ago I watched with popcorn as many online retailers scrambled at the 11th hour to build the user-journeys to support 3DS2, as the reality of mass transaction failure loomed. 3DS became mandatory in early 2021 for the EU, and late 2021 for the UK. Good times 🍿

All the bore out of the way. This seems ok. Why is it insecure?

Well, the simple answer is that the 3DS standard doesn’t play nicely with modern browser security controls.

Notably, I would go as far as to say that:

“Content Security Policy (CSP) and the Same-Site Cookie flag do not work with 3DS.” – some guy whose website you are on.

Let me explain.

Content Security Policy (CSP)

When it comes to Content Security Policy (CSP) and 3DS, there are some challenges that can arise when trying to implement either one effectively alongside the other. Such as:

How do you even surface the challenge without CSP blocking it?

CSP’s strict whitelisting of sources prevents the cardholder’s bank website from embedding. The bank’s domain used for hosting 3DS challenges will almost certainly not be whitelisted, as no merchant can feasibly pre-empt all domains for all banks.

This means that Ecommerce sites are forced to either allow iFrames from any domain in their CSP, they maintain a relaxed CSP specifically for payment pages, they migrate the whole payment page to another domain/subdomain, or they just disable the CSP altogether out of frustration.

The clear irony is that a payments page is often considered the ‘main bit’ to secure on an Ecommerce site. The ‘crown-jewel’. Having purposefully neutered security there to enable another security protocol is just weird.

It always struck me as odd that there was not some effort from Visa/Mastercard to front all banks 3DS challenges behind a unified domain/platform. While happy to mandate merchant controls, that was obviously a level of responsibility they didn’t want.

And many banks use bizarre domains and subdomains for hosting 3DS content

Which i’ve always found rather ironic from a cardholder trust perspective.

Its not seemingly expected for banks to monitor for any active sessions with the customer (on the bank’s domain) as part of the challenge process, so I suppose they are freely able to dump their challenges anywhere…

…or even shell them out to third party companies! – yes this is a thing.

Same-Site Cookie Flag

The same-site flag (which ties a cookie to the window/tab/frame in which it was set) is a bit of a problem for any application that requires a full redirect (in a new window) to a third party and back again. Why?

The 3DS flow allows a merchant to provide a redirect URL for the bank to shuffle customers back to after the challenge is complete. Suppose I have an Ecommerce website set up on example.com, and I redirect you to a new window to complete 3DS. When your bank redirects you back (using the URL you provided), your cookie isn’t sent – because you are not in the same window anymore.

This leads to some really unforgivable AppSec choices. And is an area I have found a small niche in investigating, that is typically overlooked by bug hunters.

I have seen applications which create a token for each customer during payment, where they then keep a mapping of that user’s token against their session cookie. They then share the token with the bank as part of the redirect URL for that order. When the customer comes back, they see that token, and elevate the customer back into their previous session. Problem?

The bank can access customer sessions!

Ofcourse they can. Worse still, I have seen an application which just mapped the Order-ID of that basket to the session, but where the Order-ID was actually generated by (and therefore known to) a 3rd party. Customer sessions for all!

…and it wouldn’t surprise me to find some applications directly pushing the session token itself into the URL. While this sounds unfathomably bad, its actually not much worse than the previous situations in reality… its just that the idea of someone missing the obvious fault in this one seems far-fetched.

The other option, is to disable the Same-Site flag on your payment pages. In theory you could reset the session cookie on payment pages to disable the Same-Site flag, and then reset it after the redirect to enable it again. I’ve not seen anyone actually do this, but I bet its being done.

What is vaguely amusing today in 2023 is that the new PCI-DSS requirements, following years of MageCart issues, stipulates a need to understand and document the 3rd Party Scripts that you/merchants have on payment pages. Erm, wasn’t this what CSP was for?

In conclusion, while 3DS is a vital specification for the safety of online shopping (and i’m clearly being a bit flippant when i say it is insecure), its interaction with modern browser security raises concerns that I feel need discussing. Let’s discuss!

✌️