Soatok DreamseekerDec 3

Re: https://old.reddit.com/r/crypto/comments/1pca3r8/introducing_constanttime_support_for_llvm_to/nrzywmp/?context=2

It is simultaneously true that:

  • Most data breaches do not require any cryptographic wizardry
  • Of the ones that involve cryptography, side-channels (timing, power, etc.) are not an attacker's first choice
  • The inability to have guarantees that the compiler will not make code variable-time as part of an "optimization" is a massive pain point in writing secure implementations of cryptography

And, sure, the LLVM work won't stop app developers from fucking up something on the OWASP Top 10 list for a given year. Nor will it stop phishing from being hella effective against most users and services.

But it does reduce compiler doom and various forms of auditor bikeshedding, which makes applied cryptography work a little easier to get done.

And the best mitigation we have for phishing attacks today is WebAuthn... which uses cryptography. :P

Sometimes, naysaying is actually counterproductive.

Show threadSoatok DreamseekerDec 3

If you're wondering, "Wait, WebAuthn mitigates phishing?" there's a very good explainer about this topic from the same blog that Reddit thread is about:

https://blog.trailofbits.com/2025/05/14/the-cryptography-behind-passkeys/#anti-phishing-protections

The cryptography behind passkeys

This post will examine the cryptography behind passkeys, the guarantees they do or do not give, and interesting cryptographic things you can do with them, such as generating cryptographic keys and storing certificates.

The Trail of Bits Blog
Show threadErik van StratenDec 3

@soatok : UTTER BS.

The picture you copied DOES NOT mitigate AitM's.

The article (https://blog.trailofbits.com/2025/05/14/the-cryptography-behind-passkeys/#anti-phishing-protections) is right b.t.w.

#Passkeys #AitMmadeMuchHarder #CryptographyBS

Show threadErik van StratenDec 3

How it works:

In case of https://fake-bank.com instead of https://bank.com (where you have a passkey for):

1️⃣ In your browser you open https://fake-bank.com
2️⃣ Your browser asks your passkey manager: do you have one or more passkeys for https://fake-bank.com?
3️⃣ The passkey manager replies: no

NO ASYMMETRIC CRYPTOGRAPHY RELATED TO PASSKEYS INVOLVED

🚨 When things get complicated (very rare cases)

1️⃣ Phishing mail: check your GMail account at https://sites.google.com/niceguy which you open in your browser
2️⃣ The site asks you to log in using your google account
3️⃣ Since you have a passkey for https://google.com, your passkey manager will sign the request using your passkey's private key. The signed data will include the full domain name: https://sites.google.com
4️⃣ Google is aware of this risk (see https://github.com/w3ctag/design-reviews/issues/97#issuecomment-175766580) which is why it does not let you log in.

🚨 When things get complicated AND FAIL

🔴 A hijacked domain name gets a certificate (this: https://www.bleepingcomputer.com/news/security/defi-exchange-dydx-v3-website-hacked-in-dns-hijack-attack/ won't protect you). This will not prevent a passkey-login (if the fake site acts as AitM).

🔴 Subdomain hijacking where the main domain does NOT check the full DN in the signed data.

@soatok

#passkeys #CryptoBS

Show threadCendyneDec 3

@ErikvanStraten @soatok
Soooo.. if the domain is hijacked and set up to appear identical, people's password managers wouldn't know the difference. Same with passkeys. Same with the people manually entering credentials.

That's not a problem with passkeys here, domain hijacking is out of scope.

Show threadErik van StratenDec 3

@cendyne : fuck scope.

People get promised security when using passkeys. Let's Encrypt and other DV CSP's keep issuing certs to fake and plain criminal websites.

The chain is what matters, not your limited view on "scope".

@soatok

Show threadChaz HawsDec 3

@ErikvanStraten @cendyne @soatok In the scope you’re questioning, it’s worth noting that literally everything would fail.

Look, anybody that “promised security” has something to sell, so fuck that argument too.

You’re very angry that passkeys don’t close HTTPS cert-shaped holes. But neither do password managers or anything else in a browser. Maybe the right DNSSEC + Log Transparency system can in theory, but certainly nothing running on the client can. I just don’t understand it.

Show threadChaz HawsDec 3

@ErikvanStraten @cendyne @soatok

Erik, it seems like your arguments always come down to “somebody promised me 100% safety and this only fixes problems A/B/C/D and leaves fake HTTPS certs on the table”.

I’m not saying it’s *ok* that it hasn’t been solved in this or any scope, I just think it’s a silly reason to avoid passkeys.

My advice: Set aside what “somebody” “promised” “you”.

How *can* we solve HTTPS cert problems?

Show threadErik van StratenDec 3

@chazh :

100% security is impossible. But it's bad and it's getting worse.

Fix:

1️⃣ Immediately after setting up an https connection (before downloading content), EVERY browser should warn people if they've never visited the site (exact domain name) before, if ownership of the domain name changed or upon any other risky anomaly.

2️⃣ The warning should include as much as possible information about:
• the current owner of the domain name;
• if such info is available, the *reliability* of that info.

3️⃣ Depending on said info, the user is informed about the risks they take when deciding to "trust" the website and opening it (thereby adding it to their "visited before" list).

4️⃣ User education is very important, at the very least browsers should provide easy to understand tutorials.

5️⃣ The current (corrupt) CAB/forum needs to be replaced by an organizations with end-user participation.

Google in particular does not want that. They don't want internet users to be able to easily distinguish between authentic and junk websites. Scamsites are part of their business model.

@cendyne @soatok

#BigTechIsEvil #GoogleIsEvil #CloudflareIsEvil

Show threadChaz Haws

@ErikvanStraten @cendyne @soatok

Interesting. I do agree that it’d be very naive to trust Google and Cloudflare to fix it.

I’m not sure these ideas are incompatible with passkeys. And I think the DNSSEC/Log Transparency stuff I mentioned could theoretically fit into that first-use-of-new-domain check.

Thanks for explaining it though, I do think I have a better idea where you’re coming from now.

Dec 3 at 6:24pmIvory for iOS
Show threadErik van StratenDec 3

@chazh : no, my proposal is unrelated to passkeys.

For example, if Troy Hunt had been warned that he had never visited https://mailchimp-sso.com before, he probably would not have fallen for their trap (https://www.troyhunt.com/a-sneaky-phish-just-grabbed-my-mailchimp-mailing-list/).

If a website unexpectedly sends a new certificate to the browser, this *could* be a red flag if the site used an OV or EV certificate before, and suddenly a DV cert - in that case you have no way to tell who the (current) owner is of a domain name (and website).

Be my guest if you want to use a DV cert for your home NAS (where you *know* the domain name, regardless what it looks like) or for some dumb webshop. As a visitor of the latter there's no way to know who to sue in case you get deceived.

Authenticity requires knowing, with an amount of certainty (always < 100%), who the owner is. It's all about risk management.

@cendyne @soatok

#Phishing #FakeWebsites #Authenticity #Authentic #Passkeys

Show threadErik van StratenDec 3

@chazh : one of the partners in crime. Lots of DV certificates for Cloudflare proxies are issued by "Google Trust Services".

https://infosec.exchange/@_r_netsec/115657165127445472

@cendyne @soatok

#BigTechIsEvil #CloudflareIsEvil #GoogleIsEvil

Show threadChaz HawsDec 3

@ErikvanStraten @cendyne @soatok

Now this is interesting. I have other work to do first but I’ll try to revisit it.

Seems like you’ve done some real work here considering a real problem, and maybe focusing on that could help make some real progress on it.

But, seriously, man, can I recommend that you ease up on the “Passkeys are bullshit” idea? I think, for real, if I could wave a magic wand and solve all of it, I’d probably *also* want passkeys.

Show threadErik van StratenDec 3

@chazh : I never said "passkeys are bull shit" (see https://todon.nl/@ErikvanStraten/115656347170869180).

🚨 Android, unfixed: https://seclists.org/fulldisclosure/2024/Feb/15

🚨 iOS/iPadOS (including 26.x): either
• if no fingerprint is configured
OR
• a fingerprint is configured but, under "Setting"s ➡️ "Touch ID & Passcode": "Password Autofill" is off

then a thief of my iDevice can logon to https://account.apple.com and https://icloud.com using my Apple passkey *without* scanning ANY finger or entering ANY screen unlock code.

Apple: "This is expected behavior".

@cendyne @soatok

#Passkeys #AccountLockout #AuthenticationVulnerabilities

Show threadChaz HawsDec 3

@ErikvanStraten @cendyne @soatok
Your first message in this thread was “Utter BS!” And that’s fairly typical of how you argue. It drowns out any reasoned arguments you care to offer.

Now you’re bouncing back to something else and you haven’t bothered to explain it. Calm down and explain the iOS problem for me? (I don’t care enough about Google’s ecosystem to decipher their issue, somebody else might.)

Show threadErik van StratenDec 3

@chazh :

1️⃣ Close Safari and change the setting (top left screenshot) *OR* remove all fingerprints (I've not tested Face ID, but would be surprised if such devices would NOT be vulnerable)

2️⃣ Open Safari, open https://icloud.com (or https://account.apple.com), tap Sign in, then tap (x) as shown in the top right screenshot

3️⃣ Tap in the field "Email or Phone number" to invoke WebAuthn "Conditional UI"

4️⃣ In the pop up, tap the "Use Passkey" button

Tadaa…

This does not work in ALL websites (and Chrome blocks this vuln).

Note that ALL passWORDS in iCloud KeyChain, regardless of website, can be used without local auth. Maybe something to consider when you let your kid play games or lend your iPhone to a stranger because "their car broke" and their "phone's battery is empty".

WSJ's Joanna Stern: https://youtube.com/watch?v=QUYODQB_2wQ (follow-up: https://youtube.com/watch?v=tCfb9Wizq9Q)

Fix (and, and)
🔹 Use whatever extruding part of your body to set "Touch ID", whether you use it or not
🔹 Enable "Password Autofill"

Optionally disable "iPhone Unlock".

In addition you may want to follow Joanna's advice: block making risky changes by enabling Screentime.

@cendyne @soatok @rmondello (I told him before)

#iOS #iPadOS #Passkeys #Vulnerabilities #LocalAuth

Show threadChaz HawsDec 4

@ErikvanStraten @cendyne @soatok @rmondello

I watched enough of the video to know that the first steps were 1) thief observes PIN, 2) thief physically steals phone, 3) thief uses PIN to change password.

That seems like an important vulnerability, worth solving, but *also* unrelated to passkeys. Can you slow down further and explain it in smaller words?

Show threadChaz HawsDec 4

@ErikvanStraten @cendyne @soatok @rmondello

Are you trying to say “More than a PIN should be required to unlock a Passkey”? Because I would understand that argument, and it’s a lot shorter.

Show threadErik van StratenDec 4

@chazh : no. AT LEAST a pin should be required to unlock a passkey. Every time.

Now, if a thief grabs an unlocked phone out of your hands, they don't need your pin to access your iCloud and Apple account.

Lots of people do NOT use biometrics. THEY are at risk here.

@cendyne @soatok @rmondello

Show threadChaz HawsDec 4

@ErikvanStraten @cendyne @soatok @rmondello

So what you’re saying is that there is a scenario where an important iCloud.com login allows a passkey *without* a PIN *if and only if the user disables biometrics*? Is that the claim?

I’m still trying to distill your complicated rants into single sentences so I can decide if they’re true or not.

Show threadErik van StratenDec 4

@chazh wrote:
"So what you’re saying is that there is a scenario where an important iCloud.com login allows a passkey *without* a PIN *if and only if the user disables biometrics*? Is that the claim?"

Yes.

But ALSO if the user DOES NOT disable biometrics, but switches off "Password AutoFill".

> "I’m still trying to distill your complicated rants into single sentences so I can decide if they’re true or not."

You asked me to write about the Apple vuln, which I did. So I presume that you followed the steps I described in https://todon.nl/@ErikvanStraten/115658045799601168.

What was the result?

@cendyne @soatok @rmondello