Re: OT: Passkey usage

On Mon, 2026-08-17 at 15:33 +0930, Tim via users wrote:
> Tim:
> > > As long as the system isn't weak against replay of a certificate
> > > (something listens to yours, copies it, then sends the same thing
> > > to a bad system to impersonate you).  It shouldn't be possible,
> > > there's supposed to be cross-checking, and maths that do
> > > something
> > > unique each time you use your credentials, but some badly
> > > designed
> > > systems have failed that way.
> 
> Patrick O'Callaghan:
> > As the passkey is never sent over the wire, there's nothing to
> > copy.
> > The server sends a unique one-time challenge which the device signs
> > using the private key. The server verifies the signature using the
> > stored public key in order to authenticate the device.
> 
> The write-up I read mentioned a Microsoft server (no surprises) being
> vulnerable to a replay flaw.  It didn't specify exactly what info was
> vulnerable.  So, based on what you've said, the one-time challenge is
> probably the flaw (not being so "one-time").
> 

I assume you mean:
https://arstechnica.com/security/2026/08/heres-why-the-new-pass-ta-key-attack-is-mostly-a-nothingburger/

As with most Ars Technica security reports, it has to be read carefully
to get what is actually being said beyond the headline. The flaw is not
with the one-time challenge but with the "secure" enclave on Windows
machines. This is the key paragraph:

   "Unlike all the other platforms, Windows apps generally run with all
   the privileges of the user, whereas other platforms encourage the
   restriction of the privileges of each application by default. While
   Windows provides some sandboxing protections designed to isolate
   apps, it doesn’t prevent unsandboxed apps, such as malware, from
   accessing the data of a sandboxed app. That is, the sandbox only
   protects in one direction. Sandboxing technologies on other
   platforms are much more protective."


i.e. on systems where Windows is not using the hardware TPM (for
reasons already discussed), there is a possible loophole.

> As a tangentially related thing - how many people use PGP with email?
> Ideally we all should, whether that be signing or encryption.  But
> most
> do not.  Most because it's not simple enough, some because they'd
> rather have less proof that *they* said something, and some because
> encryption would be forbidden in their country.  Personally I'm not
> that concerned that a TLA could decrypt my messages since I'm not
> some
> kind of counter-revolutionary planning something, it's probably
> enough
> that some felon couldn't easily read a private message saying on what
> dates I would be out, or exploiting medical information.  But if
> you're
> a whistleblower on government transgressions, you really do want
> actually secure messaging.
> > 

That's a different issue, i.e. privacy vs. authentication. Nothing
about passkeys has anything directly to do with privacy, but of course
systems that protect privacy also need to do authentication. There's an
oft-cited paper from years back titled "Why Johnny Can't Encrypt",
which addresses the whole usability question. Turns out that even
experienced cryptographers (or teachers like I once was) have to think
carefully when using PGP/GPG.

> > The potential weakness is when the private key store itself is not
> > secure. Ideally, it should be in a secure hardware enclave. e.g. a
> > TPM
> > or similar on the device, or a hardware token such as a Yubikey,
> > but
> > this makes it impossible to copy. Since people usually want to be
> > able
> > to log in from multiple devices and no-one wants to have to
> > register
> > each device independently, this creates a problem
> 
> And as I mentioned, people being unaware of having to individually
> register each thing.  Every attempt /that/ user had (even with
> technical support doing it for them) resulted in the newly registered
> device unregistering the previously registered device.  The service
> provider was incompetent, and created chaos.

No doubt.

poc
-- 
_______________________________________________
users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new