So you’re telling me you wrote an unsalted, date-seeded, unsigned, deterministic password generator?

In the initial interview, the client expressed a desire to modernize their security. They wanted someone with multiple iterations of implementing other types of authentication. MFA, passwordless device flows, SSO. I told them I was pretty well versed in SAML and OIDC, and had some hard-earned experience doing multi-generational technology leaps, and thought I might be well suited for the task. I even worried that I had insulted the manager’s competence by claiming Basic Auth is (still) a useful stepping stone in some scenarios.

It turns out I had overestimated the company’s security posture. Within a month I learned about the PWOD (pronounced PEE-WAD). The idea behind the PWOD was that, because the company was a SAAS with lots of tenants, they needed a way for engineering and client services to log into their customers’ tenants. They didn’t want some kind of fixed backdoor password, as that would be insecure. So instead they built a mechanism to generate a new password each day.

Because the tenants were isolated, they didn’t have any shared data, so the developers wanted something they could use without having to sync data.

So, to gain access to a customers’ system, the client services team members would go to an internal webpage which would list a daily password (and in fact, the passwords for some number of days into the future). Their implementation of this daily password scheme was

1. Deterministic, seeded by the date
2. Unsalted, the same password for all tenants
3. Easily reverse engineered

We made the case that customers would be upset if they knew that there were shared master credentials between their systems and their direct competitors. These three facts meant that an ex-employee’s access couldn’t be effectively terminated, because merely knowing the algorithm granted access in perpetuity. I’m sure you can think of other reasons this scheme seems bad.

I’ve faced active, multifaceted nation-state attacks on systems with WAY less valuable data. When these happen, they are some mix of brutal (as in brute-force) and sophisticated (as in zero-day exploits and social engineering). I’m not even sure most smaller SAAS companies would know they’ve been compromised until a ransomware lockout occurs.

You’d think this would be an existential concern, giving the heavy-hitters the company counted amongst its customers, but we found out that we were not the first ones to raise this concern, and that forcing the issue meant spending precious political capital.

In the end, I spent every dime of political capital I had trying to rally behind a solution, and everyone involved was relieved when I eventually departed.

I’d like to point out here that, although this is certainly not “best” practice, a few small changes could have increased their security posture considerably without disrupting the client services workflow.

• Generate credentials per-user, per-session
• Don’t seed by date
• Salt the algorithm
• Mandatory expiry

Additionally, to do the actual authentication

• Issue a token instead of an opaque secret
• Put an expiration in the token
• Sign the token with a private key, expose the public key to all tenants

(if this sounds like a JWT, it basically is)

Or, if all of that is too hard, at least…

• Have the tenant’s auth login system turn around and phone home to ask if the credential is legit.