Credential and identity testing: when the login is the whole building

For many large organizations, single sign-on (one login that opens dozens of systems) has quietly become the real security perimeter. That makes the identity layer worth more to an attacker than any single application. A state-owned enterprise asked us to test that layer end to end before its regulator did.

ILLUSTRATION: IDENTITY LAYERS TESTED

Auth
MFA, OTP, lockout

Session
Fixation, hijack

Exposed creds
Git, APK, JS

Priv-esc
Role → admin

The organization

A state-owned enterprise ran single sign-on (SAML/OIDC) across 60 applications for 18,000 staff. Those applications included its HR system, its e-procurement platform and a portal used by outside vendors. Shortly before it called us, it had weathered a wave of credential stuffing, where attackers try large lists of stolen passwords against the login page to see which ones still work.

What worried the client

A national data protection audit under the Personal Data Protection Law (UU PDP) was coming. The board wanted more than a check of the login page. It asked us to test the whole identity layer, including the human habits that break it, such as staff reusing passwords and developers accidentally leaving credentials in code.

How we approached it

We tested identity the way a determined outsider would, then confirmed each issue safely.

  • Authentication flows: password policy, lockout, MFA bypass, one-time-password brute force and replay, magic links, and OAuth consent abuse
  • Session management: fixation, timeout, concurrent sessions, token storage (localStorage versus httpOnly cookies) and whether logout truly ends a session
  • A sweep for exposed credentials across Git history, mobile app packages, JavaScript bundles, Postman collections, cloud storage and Jira tickets
  • An authorization matrix checking who can reach which object and action, both sideways and upward
  • Test cases drawn from the OWASP testing and verification standards for authentication, sessions and access control

What the testing showed

Four issues stood out.

  • Critical: a long-lived GitHub access token sat in a public fork’s .env.example file, and it let the build system assume the single sign-on admin role because its scope was never restricted.
  • High: the one-time-password check accepted unlimited tries with no rate limit, so a six-digit code could be brute-forced within roughly a four-hour window. We proved this safely in a staging copy.
  • High: a legacy procurement interface trusted an unsigned token, so changing a single value from role=user to role=admin was enough to gain admin rights.
  • Separately, more than 1,100 employee credentials appeared in public breach data, and several were reused for single sign-on. A scoped, forced password reset followed.

What changed afterwards

The exposed token was revoked and the build system was cut back to least privilege. One-time codes were throttled and expire after five minutes, and the procurement interface now only accepts tokens on an approved list. A retest confirmed the fixes held. The client also adopted secret scanning before every code commit and a quarterly sweep for leaked credentials. The evidence pack it needed for the UU PDP and ISO/IEC 27001 audits was delivered and accepted by the auditor.

Any organization where one login opens many systems is worth testing this way, because the login has become the building’s front door.