Summary:

• A tool called badkeys is developed to check cryptographic public keys for vulnerabilities. During a presentation Q&A, it was asked if badkeys had been used in OpenID Connect setups, and it hadn't until then.
• OpenID Connect is a single sign-on protocol with a configuration file in JSON format at https://example.com/.well-kno... (e.g., Google's at [https://accounts.google.com/....]). It contains a "jwks_uri" pointing to a JSON Web Key Set with cryptographic public keys.
• By scanning the Tranco Top 1 Million list and SSO-Monitor hostnames, around 13,000 hosts with valid OpenID Connect configs and JWKS were identified.
• JSON Web Keys have a peculiar property where public and private keys look similar, with only the private key having an additional "d" value. Using a private key instead of a public key usually works as it is a valid public key.
• 9 hosts had actual private keys instead of public keys among the collected OpenID config keys. 7 hosts had 512-bit RSA keys (long breakable) and 45 had 1024-bit RSA keys (breakable by powerful attackers).
• Running badkeys on found keys uncovered 18 hosts with "Public Private Keys" where the corresponding private key is in public software. All 512-bit RSA keys and uses of example keys have been reported, but most remain unfixed.
• Overall, 33 vulnerable hosts were discovered out of 13,000 detected OpenID configs (0.25% vulnerable). The severity of a private key break depends on how authentication tokens are exchanged.
• Two issues could have been prevented by better specifications: using the same serialization format for public and private keys in JSON Web Keys, and not supporting short RSA keys. It is recommended to add checks for private keys in OpenID Connect implementations and use standardized test keys. Badkeys now has a --jwk parameter to directly scan JSON Web Key files.
• Thanks to [Daniel Fett] for the idea and feedback, and [Sebastian Pipping] for valuable feedback on the blogpost. Image source is SVG Repo/CC0.