I don't get the sense that regular people get data "stolen".
Ransom is the only thing I see happening to end user data.
Credential thefts facilitate theft of money. It might might help the attacker to rifle thru somebody's data to find information that helps answer "secret" questions, to trick friend and family into getting phished, and maybe blackmail, but I don't see a market for end user data that would drive data theft. Nobody is buying end user photos, videos, email, etc. (Anybody who would possibly buy it just tricks/entices users into giving it to them for free to train their AI models anyway.)
LLMs ironically are changing this[0], but at least until now, rifling through random people's data did not scale, so aside for a subset of cases where it was possible to automate access to some services or otherwise leverage them into a scam on the cheap, it wasn't of interest because there was literally nothing useful to do with it.
--
[0] - LLMs, whether multimodal or combined with modern AI-driven STT / TTS pipeline, enable running highly personalized scams cheaply and in an automated fashion, which does scale up and suddenly makes this data important. But that's a very new consideration, one which passkeys were not designed for, because it literally was not possible or conceivable even few years ago.
At the scale you'd expect that to happen, looking at credential dumps, you'd also expect to hear a lot about it.
And yet, you don't. Which leads me to the conclusion that the data dump are overblown.
I think companies around the world come to the same obvious conclusion, which is why these data breaches keep happening, and the companies whose systems were breached are never any worse for the wear.
> Not active now, but given how Google+Apple already use the passkey feature to lock you into their ecosystems, it is just a matter of time until their service will require that the passkey is attested from a non-rooted Google or Apple device.
I'm with you 100%.
There will be evil and stupid uses.
The brain-damaged people who think disabling paste on password fields is a security feature will be all over forcing device-attested passkeys as soon as they learn about it.
Evil people will see it as a proxy attestation of humanity.
Either way it will be rammed down our throats if passkeys are widely adopted.
It's beyond annoying. It's creating needless toil that no "normies" will ever actually do.
I'd love a hardware sold in multi-packs and "born" at the factory with identical internal device key encryption keys (DKEK). I'd love, even more, if a token just allowed you to "commission" new ones w/ a user-specified DKEK on first use.
I'd use one token as a daily driver and store the other(s) in safe location(s), empty of my personal key material. (Or, if I can just commission a new token w/ my DKEK, store a printed copy of my DKEK in a safe location.)
Give the token a mechanism to "type" a backup of its internal state, encrypted with the DKEK, as a USB HID keyboard. That gives me an easy way to backup the token each time I enroll a new website.
If I lose my daily-driver token I just pull a spare from storage, import my last backup, and I'm up and running.
That would kick ass. No "You just need to buy two tokens and enroll them in every website" bullshit.
Maybe each token also needs a second key, with the DKEK used for authentication and the second used only for revocation. The main reason not to reuse the DKEK is so a lost key can be easily decommissioned.
You would need some out of band way to collect and save your key IDs and publish revocations.
I’m not sure if this would work from a security theoretic perspective, need to think about how the request is signed and transmitted so someone can’t fake a key being “alive” when it’s really “dead”.
I do agree this would be incredibly useful if it can be made to work.
I haven't used a FIDO2 token other than playing around with it on a Yubikey. There, at least, I have to have the PIN to unlock the Yubikey before I can use the FIDO2 credentials (if I'm remembering correctly).
Are there hardware token implementations where mere possession of the token is all that's necessary to use the passkeys stored on it? That's incredibly stupid, and should have been disallowed by the standard, if that's the case.
Yes, the PIN is optional even on Yubikeys, although I think individual providers can require it. Ideally a strong PIN should be used but people may just reuse their ATM PIN, birthday, etc.
That is how almost all standard FIDO2 tokens work. You just have to press the capacitive sensor when prompted. You can get fancier biometric tokens that require a fingerprint.
> ...run it in some kind of secure container which has access to read browser history, and write to its database, but definitely does not have network access.
We should be doing this with all software, regardless of provenance, anyway. Least privilege applies to servers just as much as it does to users. Even if the software isn't untrustworthy you can be it has vulnerabilities.
My first go-to is network segmentation because I spend most of my time doing networking work. For every vendor who has shit-talked me to Customers ("Wah, wah! Your networking vendor is making this so much harder because they want us to enumerate our traffic!") I have concrete examples I can cite when attacks were stopped by network segmentation (preventing shellcode from downloading a payload, preventing C2 communication, firing off alerts when unexpected network traffic starts coming out of a host, etc).
Beyond network segmentation, I am very suspicious of software that needs to run as a privileged user. So many attacks get easier when privilege escalation in the host OS is already done for you.
Given the number of residential proxies I see scraping the couple of sites I have responsibility for I don't find IP address-based blocking useful anymore. That ship has sailed.
Behavioral and client fingerprint analysis (ugh-- having to run Javascript just to view a static site) is the only way (at least until we get user "age" and identity attestation rammed down our throats).
I run an attractive site to AI scrapers and yes the IP ship has indeed sailed in favor of residential proxies. They are non-stop and could have ingested all of our content many times over every day. JA4 is useless too because they have the ability to spoof this or use a very common fingerprint like Chrome that you cannot block without blowback. These bots will only use a given IP a couple of dozen times and then use another node. They use 10s of thousands of IPs. You can tell because they will come in waves from a residential or mobile network
What kind of fingerprinting are you thinking of? JA4? I haven't found a way to do that inexpensively at our scale, but we may have to go that route - looking at CloudFront bot mitigation.
For behavioral, we have Anubis honeypot functionality turned on, but it doesn't seem to be effective for 99% of scrapers. Anubis is also running behind TLS termination, so I don't think it can do full JA4. It does have the less robust JA4H apparently, but I'm not sure how effective that will be.
Edit: Oh yeah, forgot to mention - it's almost 100% residential proxies. Primarily China Telecom and China Unicom. Unfortunately those providers are HUGE and also host a ton of legitimate users all over Asia.
> What kind of fingerprinting are you thinking of?
I'm minding a proprietary application where this is being discussed. The vendor is talking about running Javascript in the client to detect headless browsers, bots, etc. I'm guessing they're going to license something off-the-shelf. The technical specifics aren't being discussed. They're at the "wow the stakeholders" phase.
I'd like to do something ourselves but, at the size of the org I'm talking about (with virtually no in-house dev resources), COTS rules the day.
Any path can be made into an optical path with a bright enough light. >smile<
reply