QRAuth
QRAuth signs QR codes with an organization's cryptographic keys so scans can be verified, for developers and security te
The Problem
A vanilla QR code is just a URL hidden behind a barcode, and neither the user nor their browser can tell what it resolves to until it's too late. The page cites 71% of scanned QRs going to a URL the user has never seen, and a 450% year-over-year rise in 'quishing' attacks targeting payment QR codes (ENISA 2025). The median scan-to-action time is 3.2 seconds, too fast for a human to verify anything. A vanilla QR carries zero cryptographic guarantees, so anyone can print one impersonating anything, and phone-level trust hardware like secure enclaves and passkeys has no equivalent at the QR layer.
The Solution
QRAuth signs every QR code with an organization's keys and verifies it on scan, binding the result to a hardware passkey via WebAuthn/FIDO2. It layers four independent signatures: Living Codes (HMAC-SHA256 frame rotation every 500ms to defeat freeze-frame capture), an ECDSA-P256 issuer signature for provenance, a post-quantum SLH-DSA signature run in hybrid mode, and device binding to a specific user-device pair. The platform ships as three flows sharing one key store, dashboard and audit log: passwordless authentication, QR verification for printed or public codes, and delegated, time-limited access. Developers integrate via Node/Python SDKs, an OpenAPI spec, HMAC-signed webhooks, a docker-compose local dev stack mirroring production, or a single '<qrauth-login>' web component (Shadow DOM isolated, CSP-clean, SRI-pinned, ~10KB gzipped). It is built on QRVA, a published vendor-neutral protocol, with the platform itself licensed BSL-1.1 converting to Apache-2.0 on a fixed timeline, and SDKs/web component under MIT.
Why Now?
Phones now ship with secure enclaves, biometric attestation and WebAuthn passkeys, but the QR layer hasn't caught up, and quishing attacks are cited as growing 450% year over year, creating a gap QRAuth positions itself to close.
