[3.0] External authentication (part 3 of 5) — lets members sign in with a passkey

[albertlast]

Do not merge without #9492. On its own this PR lets anyone holding a member's session attach a permanent new way into their account, which a password change and a logout both fail to revoke — so it removes an eviction lever the forum has today. #9492 puts a re-authentication check in front of it. See the merge order note on #9381.

Description

Part 3 of a series that gives SMF a way to sign in that is not a password.
Part 1 (#9381) made the login completion reusable and added the credential
table; part 2 (#9488) added OpenID Connect. This part adds passkeys.

A passkey is a key pair the member's device makes and keeps. Registering one
means the forum is handed the public half; signing in means being handed a
signature and checking it against the half we kept. It is unphishable: the
browser writes the origin into what gets signed, and a site pretending to be
this forum cannot make it write ours.

What a member sees. A "Passkeys" area in their profile where they can add
one and name it, and a "Sign in with a passkey" button on the login form —
plus the passkey offered directly in the username field's autofill list, on
browsers that support conditional mediation. Neither appears unless the
browser actually has the API, because the script adds them rather than the
template printing something that would be dead for everyone else.

What an admin sees. A new Authentication area in the ACP, with the
existing provider list moved under it and a Passkeys page beside it. Off by
default. The page states which domain passkeys will be tied to, since that is
taken from the forum URL and changing it later invalidates every passkey with
no way to move them.

Implementation notes, and the arguments behind them:

• Bundled, not a dependency. Sources/WebAuthn/ follows what
  Sources/TOTP/ already does. It is a CBOR reader, a COSE key to PEM
  converter, the authenticator data structure, and the two ceremonies —
  small, because only what authenticators actually send is supported and
  anything else throws rather than being guessed at.
• Two algorithms. ES256 and RS256 are the only ones offered, because they
  are the only ones we can verify. Offering more would mean accepting a key
  we cannot check.
• No attestation. It is neither requested nor examined. Attestation says
  what make of authenticator produced a credential, which only matters to a
  site policing a list of approved models; verifying it means shipping trust
  anchors and keeping them current, and getting it wrong locks out honest
  members. None of the security of signing in rests on it.
• openssl stays optional. The feature hides itself when the extension is
  missing rather than raising what SMF requires everywhere.
• Discoverable credentials are required, since that is what lets the browser
  offer the passkey before anyone has said who they are.
• User verification is required by default, and the setting is the opt-out,
  so the safe answer is the one an install gets without anyone choosing it.
• Credential IDs are stored hashed. They run to a kilobyte and MySQL indexes
  only the first 191 characters of the column, so two different credentials
  could collide on the indexed part. The ID itself is kept beside the key.
• A sign counter that has not moved forward is logged, not acted on. It is
  the one hint the standard gives that a credential was cloned, but plenty of
  authenticators never count at all, so refusing would lock members out over
  a quirk.

Not in this part: passkeys as a second factor alongside TOTP. That lives
behind ?action=logintfa, which cannot render on release-3.0 at all —
LoginTFA::execute() reads User::$me->dataset after verifyTfa() has reset
the member to a guest, and a guest's dataset is null. That is a separate
bug, unrelated to this series, and worth its own fix first.

Verified, since CI only proves the code parses:

• 66 checks over the primitives with no browser involved: CBOR decoding
  including the malformed cases it must refuse, COSE to PEM for both
  algorithms — the rebuilt PEM is byte for byte what openssl produces for the
  same key — signature verification, authenticator data parsing including
  finding where the public key ends when extensions follow it, and both
  ceremonies against a forged authenticator.
• 43 checks over real HTTP against a running forum with a synthetic
  authenticator: registering, listing, the duplicate refusal, the exclusion
  list, passwordless sign-in ending logged in as the right member, the sign
  counter written back, removal, and the admin page. Refusals cover another
  origin, another relying party, a key we never saw, an unregistered
  credential ID, a challenge already spent on a failed attempt, an assertion
  answered in a different browser session, and a ceremony with no session
  token — none of which logged anybody in.
• composer lint, phplint on the whole tree, and the four integrity checks.

Note that composer lint only looks at tracked files that git already knows
changed, so it silently skips new files; these were checked by pointing
php-cs-fixer at them directly.

One fix outside the new code: Credential::listFor() did not select
secret_data, so anything reading it back got nothing. It is what the
exclusion list is built from, and the test above is how it was found.

Issues References (Fixes|Related|Closes)

1. Related: [3.0] External authentication (part 1 of 5) — lets something other than a password log a member in #9381 (part 1 of 4), [3.0] External authentication (part 2 of 5) — lets members sign in with an OpenID Connect provider #9488 (part 2 of 4)
2. Related: [3.0] Fixes password reminders never validating #9380, the reminder fix this series was built on top of