One PennKey, 1.2 Million Records
BleepingComputer and Specops recently resurfaced the University of Pennsylvania SSO breach — an incident in which a single compromised PennKey single-sign-on credential exposed roughly 1.2 million records. Not 1.2 million cracked passwords. One. One legacy credential, standing in front of everything that trusted it.
That is the uncomfortable arithmetic of single sign-on. The entire pitch is consolidation: one identity, one login, every app behind it. Which means the moment that one identity is phished, reused, or lifted from a breach dump, the attacker inherits the same convenience your employees enjoy — instant, authenticated access to everything at once.
Blast Radius Is a Design Property, Not an Accident
Security teams talk about “blast radius” as if it's something that happens toyou. With SSO it's something you architect on purpose. Federate VPN, CRM, ERP, and your document store behind one identity provider and you have decided, in advance, that a single credential compromise is a full-portfolio compromise. VPN into the network. Salesforce for the customer list. SAP for the financials. SharePoint for everything written down. One key, every door.
This isn't an argument against SSO — federation is genuinely good for management, provisioning, and offboarding. It's an argument about what you put behind it. If the thing behind your identity provider is a typeable, reusable secret, you've built a castle with one gate and painted the key gold.
NIST Moved On. Length and Screening, Not Complexity.
The updated NIST SP 800-63B guidance quietly buries the theater we inherited from the 2000s. The headline changes:
- 15-character minimum for single-factor credentials.
- 8-character minimum when the credential is paired with MFA.
- Mandatory breach-list screening for every new credential — check it against known-compromised corpora before you ever accept it.
Notice what fell out: the forced symbols, the mixed case, the arbitrary-complexity rules, the 90-day rotations. NIST's own research killed those years ago because they push humans toward predictable passwords, not strong ones. The direction of travel is unmistakable — length and breach-screening over complexity. The guidance is, in effect, an admission that the human-chosen secret is the weak link, and the best you can do is make it long and check it hasn't already leaked.
The Honest Reading of That Guidance
Read NIST's trajectory forward and it points somewhere specific: every rule is a patch on the same underlying defect — that the credential is a shared, reusable stringa human types and a server stores. Fifteen characters is a bigger lock on the same door. Breach-screening is a way of asking “has this exact key already been copied?” Both are damage control for a secret that can be phished, reused across sites, and dumped into the next 24-billion-record database.
FaceIn: Nothing Behind the Front Door Worth Stealing
FaceIn attacks the defect instead of the symptom. There is no legacy credential to phish, reuse, or screen against a breach list — because the secret never leaves the user's device and is never typed. Authentication is a fresh, single-use cryptographic proof bound to that device and that moment. Put FaceIn behind your identity provider and a stolen login stops being a master key: there is no reusable value to lift, so “one credential unlocks everything” becomes “there is no credential to unlock it with.”
SSO's blast radius comes from concentrating trust in a single identity. That's fine — ifthe thing proving that identity can't be copied. Every SSO blast-radius incident that hits the news is another argument for making the proof unstealable rather than making the password longer.
The Takeaway
One PennKey, 1.2 million records. NIST responding with longer minimums and mandatory breach-screening. Both tell the same story from opposite ends: the reusable secret is the problem, and every fix short of removing it is just a taller wall around the same weak gate. The question for anyone running SSO is simple — when your one gate is breached, do you want the attacker to inherit a working key, or to find there was never a key to inherit?