Verified by Visa
and
MasterCard SecureCode
– or, How Not to Design Authentication
Steven Murdoch and Ross Anderson
Cambridge
Single Sign-on Systems
• Since mid-80s, we’ve seen products that let
you use one password for multiple systems
• What do you think is the most successful
single sign-on system ever?
– Microsoft Passport / InfoCard?
– OpenID?
– Liberty Alliance?
• Actually, it’s none of these…
3-D Secure
• Branded as “Verified by Visa” and “MasterCard
SecureCode”; hereinafter 3DS
• Lets you use a password with your credit card to
pay at many merchant websites
• Like Passport, OpenID etc, it redirects you to a
central login service
• It was the card industry’s answer to a big rise in
card-not-present (CNP) fraud that followed the
introduction of the Europay-Mastercard-VISA
(EMV) smartcard payment system
Fraud in the UK since EMV
How 3DS Works
• Customer presents card to merchant
• Merchant passes card number to its bank (the
acquirer) who supplies a URL for logon
• The URL is often to a third-party service such as
RSA
• The logon page was originally presented as popup
• Because of popup blockers, the standard now
recommends that the merchant embeds it in an
iframe
User Interface (1)
User Interface (2)
How 3DS Works (2)
• If successful, auth code is returned for merchant
using TLS and client certificate
• Similar systems are being introduced (or are
planned) for more and more payment systems
– VISA original credits
– Single European Payment Area (SEPA) e-Mandates
• The latter will replace cheques in Europe!
• So how secure is all this?
Technical Security (1)
• Implementation is left to individual banks and
their contractors
• Some make truly shocking choices – like reusing
ATM PINs as online 3DS passwords
• Best practice is to authenticate the bank too – with
a memorable phrase from the customer
• But this is still open to man-in-the-middle attack
• So we’re now seeing a variety of phishing attacks
Phishing (1)
Technical Security (2)
• Banks should mail out passwords – but to save
money most do Activation During Shopping (ADS)
• So a merchant website suddenly enrols you!
• Weak auth – e.g. date of birth (Bank of Scotland)
• Banks are not supposed to compel registration until
after three transactions, but many ignore this
• Also, if you forget your password, many banks just
rerun the enrolment protocol
• All this also gets used in phishing …
Phishing (2)
Security Usability
• Users should only enter bank credentials at bank
URL to which they have navigated (or at least
which they’ve checked)
• Our industry introduced cues such as extended
validation certs and browser toolbar colour
• The banking industry via 3DS has trashed this
completely!
• Our first encounter with securesuite.co.uk
• So why should the computer industry be helpful to
the banks in future?
Privacy
• SET gave the bank and the merchant only the data
they needed; InfoCard prevents profiling at all
• 3DS collects full transaction data
• And it’s mostly run by contractors like RSA who
accumulate huge databases of transactions
• We might then worry about FBI national security
letters, spear phishing, corrupt employees...
• Will there be a big bust-up as with SWIFT?
Security Economics
• 3DS is easily the worst secure signon protocol
ever; why did it succeed?
– Merchants are no longer as liable for transactions they
push through 3DS
– Users lose statutory protection of signatures; typical
contract says customer liable for all uses
• While InfoCard and OpenID had good engineering
but no incentives for adoption, 3DS had bad
engineering but strong incentives
Policy
• 3DS is abusive – customers get little or no
protection but a huge increase in liability
• What’s needed is transaction authentication – e.g.
modify 3DS to include SMS, Cronto
(Commerzbank, Germany) or CAP interaction
(Ogone, Belgium)
• Regulation: at present, a liability shift is allowed
under Europe’s e-signature directive if the
customer has a secure signature creation device
• The missing word is “only”!
Conclusions
• Single sign-on provides a telling case study in
security engineering
• Previous offerings like OpenID and InfoCard got
the engineering right but the economics wrong
• 3D Secure got the engineering wrong but the
economics ‘right’ (at least for the banks)
• It’s the one that succeeded
• The outcome is abusive to customers (and
merchants hate it too). Regulators ought to fix it
• It contributes to growing systemic risk (recall the
hassles of registering and booking!)