The Krypton Second Factor

"Speak, friend, and enter" - West-gate of Moria

I loved watching The Krypton Factor in the late 80's. It was a series I remember as a child where contestants were put through a gauntlet of physical endurance, mental agility, logic puzzles, and bizarrely specific problem-solving challenges. As the contestants wrestled with their tasks, I remember the host’s sultry, smug voice-over with phrases like: “Michael will never progress in this challenge until he moves the red peg into the blue hole.” Yep, real easy when you're not Michael!

Today authentication landscape is no less challenging than The Krypton Factor of the 20th century:

• Complex rules
• Hidden constraints
• Multiple modes of failure
• Important but silent assumptions
• And a tendency to punish for failing to intuit the one exact thing the task expects

Modern Authentication – Necessary, but Necessarily Evil?!?

I am not anti-security. I worked IT security for decades!

I’m old enough to remember when passwords were routinely stored in plaintext, when SSL was an optional extra, and when “just put it behind a firewall” was an acceptable security design. I’ve designed auth systems, and made use of many more.

So when I say this, I say it with affection and fatigue: Every time I see a new 2FA or token-based authentication requirement, my heart sinks. Not because it’s hard in theory or unfamiliar, but because experience has taught me what comes next. Take a deep breath. Pray. And then spend 15 minutes implementing and three hours debugging a “simple” and “standard” authentication flow.

Just Recently

What prompted this post was npm recently changing from “classic” token authentication for publishing to “granular” tokens. After hours of failing to get a simple new token to work, I discovered that the scope I was publishing to was taken. I’d checked for it in the Web UI incorrectly and assumed it the scope was free to use. It was a simple enough condition, and a simple “that scope is already taken” error message on “npm publish” would have saved a few hours of frustration.

While this was largely a skill issue, it got me thinking about the last few third-party authentication interactions I’d had. None had been great.

Github OAuth2 – didn’t support multiple callback URLs – requiring a terrible coupling between production and non-production environments. A fiddly redirect tap-dance and cross-environment dependency resulted.

Facebook OAuth2 – requires you to publish a production login flow that’s not going to work for users just to get their blessing. Sure, several workaround options could handle this, but should you really need them?

Google OAuth2 – struggled to load the right thing into the right window and ended up requiring a localStorage hack to signal between popup and main window, after repeatedly and completely failing to postMessage() across the two. Not really Google’s fault there, but just another example of the kind of thing that inevitably goes wrong with this stuff.

I could go on.

Complexity++

Token-based and 2FA-based systems already ask more of developers:

• More concepts
• More states
• More configuration
• More places for subtle failure

It therefore behoves the implementers of authentication systems to smooth the ride as much as possible.

Psychologically, I’m scarred. When I get to the point of having to implement authentication to a third party 2FA or OAuth2 system, my first though isn’t:

“great, this is secure”

It’s:

“great, there goes my afternoon”.

To be clear, I’m not opposed to 2FA, token-based authentication, OAuth2 or passkeys. I’m opposed to unnecessary pain in their implementation!

Some Non-Unreasonable Requests of Authentication Systems

If you’re implementing an authentication and authorization system, then maintaining the security of the system is the unquestionable priority. But this is not mutually exclusive with a good developer experience. Consider these:

1. Error message precision

Authentication systems are one area where vague, generic and non-committal error messages are encouraged in the name of security.

“A hacker shouldn’t know what’s going on”.

While this is a consideration, consideration should also be given to the developers and users on the other end of the system who are JUST TRYING TO GET LOGIN WORKING! Authentication is the welcome mat to the rest of your functionality, so do your best to be a good host!

2. Multiple environment support

Consider if your system would conceivably used from different environments, and ensure that your design caters for this.

3. Documentation

That old chestnut! I like good-to-go Postman collections for APIs, but at least clear documentation on the steps to take to get the system working. If there are common pitfalls for implementers, then – well – a “common pitfalls” section would be great as well!

Closing Thoughts

Modern authentication is hard. But making it clear, humane and debuggable is not out of reach!

If even experienced developers have the same physical reaction to “enable this 2FA or this token-based auth system”, that’s not resistance to security. That would be trauma!

Like The Krypton Factor, authentication systems too often become an aptitude yea even clairvoyancy test. Somewhere, a red peg needs to go into a blue hole — but nobody tells you that! You're left with no clue what the "403 Forbidden" actually means.

Can our industry do better here? Definitely! Will we? I’m...not sure.