Meeting minutes
The minutes of this joint meeting are public.
Patterns in payment fraud
Erhard: I'd like to take you through some patterns we've seen and some possible solutions.
[On Entersekt]
Entersekt: Some of our clients use us for authentication during 3DS challenge flows; we also have our own ACS
… online sales increase and fraud grows every year.
… anti-fraud workflows are difficult to build
… security v. usability (and cart abandonment)
… we'd like to have seamless MFA.
… exceed regulatory requirements
… use contextual authentication where possible
… payment fraud is an entire value chain
… fraudsters steal passwords and cards, attempt small purchases, attempt logins, attempt logins to extract PIIs
… Account takeover: Phishing
… all you need is an email address and phone number.
… some of this can be mitigated through 2FA and through education.
… Account takeover: SIM Swap
… requires credit card number and PII
… so OTP codes sent to another device
… can be mitigated by looking at SIM age
Account takeover: Social Engineering
required - bank details, some PII
… fraudster poses as bank employee
… to mitigate: behavior biometrics and clear messaging to user (e.g., account information, specifics)
Chargeback fraud (where 3DS not widely used)
… required: credit card number, customer PII
mitigation: 3DS challenge flow
Triangulation Fraud (which is less common)
required: customer PII
mitigation: 3DS challenge flow
… use descriptive messages during 3DS
Erhard: COVID-19 has fueled a surge in e-commerce, but corresponding rise in account takeover
… card tokenization can help mitigate stolen cards
… ability to recognize returning browser would help more mitigations
… some attacks:
* Card sniffing / skimming attacks. Relies on cross-site scripting
… compromised JS executes in the payment page. Upload collected data
… there were 17K domains affected by a 2019 attack
mitigations: JS integrity hash; CSP
* Card testing /card cracking fraud
… JS used to test stolen credit cards
… most common form of fraud in NA in 2021
mitigations: use 3DS, velocity checking, origin IP address monitoring, monitoring multiple declines on card, bot detection
Erhard: XSS is still a widely used attack
… browser fingerprints can be spoofed
… CSP rules often lacking or not implemented.
Erhard: study of 1000 sites in 2020 found 92% of evaluated websites expose data to 17 domains
[How to address fraud patterns]
Erhard: Browser fingerprinting is not good enough anymore
… use FIDO & SPC
… but we are looking for better signals for frictionless flows
… some ideas:
* Context aware challenges
Erhard: Geolocation - users will opt in if positioned correctly.
… FIDO/SPC even within the issuer's iframe
… register user in a 1p context (banking portal)
… 3DS checkout can take advantage of cross-origin iframe calls
… SPC can improve UX over WebAuthn dialog
… in the future, delegation with SPC
* Browser behavior biometrics
… detect velocity with the form
… you can check familiarity with addresses
… multiple logins from same endpoint
… modified browser detection
… geolocation + IP checks
Erhard: We'd like to make the most use of 3DS2 frictionless flow, which involves the Method URL
… this approach in a cross-origin context is being shut down
… we'd like to demonstrate that a user is returning to the same browser.
… can the browser ask the user if they trust this domain to improve payment experiences going forward.
Erhard: We've experimented with WebCrypto API
… you can store in indexDB and mark as non-extractable
… clearable by the user
… would be valuable if the crypto object could be tied to hardware
<svaldez> Vaguely sounds like token binding/channel binding.
Erhard: and tie into the browser attestation proposal
… take the customer through a trust ceremony where they can opt-in to be remembered on this browser.
Erhard: Hardware-backed will help avoid clearing
svaldez: Even without hardware backed, I think browsers would want to reset
… what you want is "more persistent key" not necessarily "hardware backed"
Erhard: I reviewed the Antifraud CG proposals to evaluate utility in light of these fraud patterns.
* Trust token
… this could identify a good browser, but need some way to associate with the browser.
… is there a way during remember me process that requires user consent and friction, and user opt-in, after that, the trust token could let you issue anonymously or with id provided at registration time.
trust tokens are valuable in cross-origin context as well
svaldez: The extra layer of user consent helps; just need a signature
SameerT: User consent is an important part here; they would have full knowledge. If this device attestation is happening with a user gesture, would that meet some of the criteria?
svaldez: It's not trust tokens anymore; it's just a signature
svaldez: Given user consent, the privacy impact is ok.
rbyers: Why not webAuthn?
SameerT: User consent is at registration time. Once binding has been created, at authentication time, the issuer doesn't have to challenge.
rbyers: I suspect that the browsers wouldn't be ok with "no challenge at authentication" time.
Gerhard: The friction does impose as real cost on merchants (cf Monday presentation from Microsoft)
… maybe there's an answer where you use WebAuthn, but where there's a way to have less friction for the next few challenges.
… this could be based on consent given through WebAuthn
… maybe it's not completely frictionless, the user still has to perform a gesture, but that can trigger a signature in the browser.
SameerT: In looking at signals come from the device, there are multiple signals (e.g., transaction data).
philippp: It seems like what we want is minimal friction and typing number in a 3p context.
… we want to reidentify the user in a 3p context for one use case
… we want the user to be informed they will identified.
… the user has entered a card number.
… the browser could do a passive check because they are not further identifying the browser.
<rbyers> I like it
John_Bradley: We already kind of have that in SPC where you talk to the ACS and get a list of credential IDs that have to be presented to the authenticator
… it is technically possible with WebAuthn to not require userPresence (possible in CTAP, but not in WebAuthn)
… in this case the goal is to silently authenticate the user in a special context where they have the credential registered.
… so a small change where SPC could request with userpresence=none .
smcgruer_[EST]: With UI in your phase
smcgruer_[EST]: I think this is roughly asking the question "how much UX is ok" to unlock the information.
… we've worked through "zero friction" to "minimal friction" etc.
… would payments folks be ok with the dialog?
… if you are willing to put something in the user's face, why not open a popup>
John_Bradley: In a 1p context, it's easy
… WebCrypto is designed to not be used cross-origins
Gerhard: Many times the merchant has card-on-file and it's tokenized
… I like John's idea where the transaction dialog is shown, but without the biometric.
… it's not an extra step for the user ; the page can be designed for just one button push
… just getting the dialog for "Yes" would be a good improvement
John_Bradley: Without any changes to WebAuthn, you can ask for noUserVerification
smcgruer_[EST]: This will require different UX. What does WebAuthn UX do on various platforms?
John_Bradley: There's extra only UX only when you are making a credential.
… platform authenticators may not allow noUserVerification
smcgruer_[EST]: What we would want to be sure of, is that the user is providing their identity to a particular entity.
JOhn_Bradley: The uX could be optimized.
SameerT: To understand this solution, we went from no user clicks to 3 steps
John_Bradley: You can do this in a 1p context (WebCrypto). In a 3p context you have to avoid tracking. We could probably collapse the UX to one click with SPC.
<Gerhard> Comment: There are 2 items/paths to explore:
<Gerhard> * Silent detection of known browser. Not currently possible even with Webcrypto since browsers can clear this at their will. And no 'registration journey'
<Gerhard> * Optimal Challenge with a single click. It's possible and will have great consent.
Ian: I'd like to work with Philipp on characterizing requirements
Erhard: Another Antifraud proposal is "device integrity attestation through the browser"
… that would be helpful for payments fraud
Erhard: There are challenges with custom browsers and those with extensions
… as discussed in the Antifraud CG
… but I'd like to explore that
Erhard: Another proposal was eTLD+1 to expose domain spoofing
… this could be useful for an ACS to detect a fake storefront
<philippp> Whether or not the browser/device is modified/automated seems somewhat independent of whether the payment instrument is seen on the same device
Erhard: How to address these fraud patterns?
* Involve customer during a browser trust process
<philippp> When we have time, it'd be good to understand the specific threats (scaled fraud?) we'd be going after with browser integrity attestation
* Some form of identifier or credential is needed for a specific customer
* Browser access to hardware backed scores storage could have a big impact
Phish in sheep's clothing
[Xu Lin's slides regarding Phish in Sheep's Clothing: Exploring the Authentication Pitfalls of Browser Fingerprinting]
Xu: Thanks for inviting me to present our current work
… I'll present our recent publication
… phishing is the most prevalent hijacking vector.
… researches found 2FA is a critical defense against these attacks.
… web sites want to minimize inconvenience
… so 2FA is sometimes triggered only for suspicious attempts
… fingerprinting adoption on top 10K sites has gone from .4% in 2013 to 25% in 2021
… advanced ris-based authentication uses browser fingerprinting.
… attackers can trick websites into not considering a login attempt to be suspicious
[Overview of our attack workflow]
… we developed 2 extensions to do fingerprint extraction and then spoofing.
… the extractor captures the site's exact fingerprinting code
… basic fingerprints are identical across sites
… advanced fingerprints vary depending on the fingerprint generation process.
… in second phase (the attack), the fingerprint is reproduced by the stolen code
… so when the user visits the phishing web site, the extension gets fingerprint code and credentials.
… then the attacker can use the spoofer extension to replace the page's fingerprint script, they trick the site into thinking it's the legit user's device
… and then 2FA is bypassed.
[Experimental evaluation]
Xu: We looked at top 10K sites
… top 10K sites employ more advanced fingerprinting techniques on login pages compared to home pages.
… 50% of bank sites are using fingerprinting for user authentication
… we wanted to see if our attack was feasible on 14 sites using our personal accounts.
[Chart of fingerprinting techniques]
… more than half were vulnerable
… we bypassed 2FA in 9/14 sites that use FP for authentication.
… what prevented our attack was IP address checks, but even in those cases we could bypass the restriction by injecting an X-Forwarded-For header
<Zakim> weiler, you wanted to thank Xu and ask (anyone) if this has been seen in the wild
weiler: (Met you at Usenix. :). Have you seen anyone doing this in the wild. Are there any known real malicious actors?
Philipp: I can attest that it's being done for account takeover.
John_Bradley: I'm surprised that this work for financial institutions. Were any of these sites using things like first party cookies that were signed? Or were they just relying on fingerprinting the browser without a cookie?
Xu: In these cases, they were not using cookies. Our focus was not cookie-hijacking
John_Bradley: I would have imagined that most sites would use cookie tracking and fingerprinting.
… these are all 1p logins
… if this was an analysis of people logging in an iframe, that would be different?
weiler: Are you assuming you can steal the cookies?
John_Bradley: But you can't. Does your domain assume you can issue fraudulent SSL certificates?
… there are ways of binding cookies to browsers.
Xu: Regarding cookies, we did find some sites that use cookies and fingerprints together...e.g., a web infrastructure web site
philippp: There's a variant of this where malware steals cookie jar.
John_Bradley: We came up with a standard called token binding in the IETF to mitigate these things.
John_Bradley: It was designed to bind TLS and cookies to a browser.
… and provided an attestation about veracity of browser.
Aram: I think both in the publishing industry and on ad-tech, we've seen fingerprinting companies go strong
… the fact that this could happen is not surprising, but the fact that it's happening to banks is a surprise.
Aram: I was wondering also in terms of what this study was showing you...did this give you an impression that there was less uniqueness among fingerprints,
or just that they were easy to replicate.
Xu: Because the browser fingerprints rely on JS APIs and the objects are mutable, it doesn't matter if they are unique
… even in some web sites we found some new fingerprinting techniques
… we are currently working on a system that could raise the bar for fingerprinting attackers.
Aram: In terms of developers who are running services in their site that are relying on fingerprinting, do you think that the top window could mitigate the possibility of this attack by blocking off some JS APIs to the windows in the page?
… such as iframe
Xu: Randomizing features could prevent attack, but it might also break functionality.
… for example, the site might end up doing 2FA for each login because fingerprint is different each time.
[Phishing and Fingerprinting]
… majority of sites are collecting fingerprints and that number is increasing with time
… we also catalog fingerprinting techniques
9-14% of sites collecting advanced fingerprints (canvas being popular for those approaches)
… sharp decline in phishing sites for a particular bank may be due tot he IP Address requirement
[What can we do to prevent attacks?]
* 2FA
* Chain sessions may help (requires memory of prior sessions)
* Combine strict IP address checks and presence of specific cookies
{user defenses}
* enable 2FA
* user password managers
<AramZS> jeeeeeez
<AramZS> I can't believe anyone was genuinely relying on fingerprints for security. The whole process was designed solely for ad targeting originally. This is insane to find out that banks are using it for auth.
<SameerT> Ian, do you have Microsoft's presentation handy?