Architecture Nugget - January 30, 2025

Bcrypt's Hidden Limits: Lessons from Okta's Security Incident for APIs design

Okta, a cloud-based identity and access management (IAM) service, recently ran into a security incident. In certain cases, a bad actor could’ve logged in as an authenticated user if that user had a long username.

The issue came from how they were using the Bcrypt hashing algorithm. Bcrypt has a max password length of 72 bytes, and in Okta’s setup, the cache key was generated using bcrypt(userID + username + password).

The problem? If the username was too long, the password got partially or completely ignored.

Obviously, that’s a security mess. But from an API design perspective, the Bcrypt library they were using should’ve thrown an error or said something like, “Hey, this input is too long — I’m ignoring part of it.”

This original article breaks down how different Bcrypt implementations handle this. Some libraries, like Go, do proper validation, while others, like Spring Security, just let it slide.

Check out the original article for the full story. The takeaway? When designing an API, don’t assume people know how to use it properly. Instead, make sure they can’t use it the wrong way.

Writer RAG tool: build production-ready RAG apps in minutes

• Writer RAG Tool: build production-ready RAG apps in minutes with simple API calls.

• Knowledge Graph integration for intelligent data retrieval and AI-powered interactions.

• Streamlined full-stack platform eliminates complex setups for scalable, accurate AI workflows.

Learn more about our production ready RAG tooling here.

Web API Design: The Missing Link

Since we're talking about API design, I have to mention a free eBook I recently came across from Google.

A good API can really be a game-changer. Its job is to make application developers as successful as possible. When designing APIs, we need to look at things from the developer's perspective.

This book dives into how to design a solid REST API, which, unlike the RPC model, is data-oriented and focuses on entities (nouns) rather than actions (verbs).

Here’s a quick rundown of what it covers:

• Web APIs and REST: It explains web APIs as patterns of HTTP requests and responses used by computer programs to access websites. REST, as the architectural style of HTTP, focuses on using HTTP directly without layering extra concepts. The book clears up the difference between HTTP (the reality) and REST (a set of design ideas that shaped HTTP). It also points out how many modern APIs mix HTTP concepts with things like RPC.

• API Design Elements: Things like resource representations, HTTP headers, URLs, and expected client behaviors.

• Designing Representations: The data exchanged between clients and servers is called a representation. JSON is recommended as the go-to media type for its simplicity and easy mapping to programming data structures. It also suggests including links to represent relationships.

• Designing URLs: Stick to nouns, not verbs. URLs should identify resources, not processing algorithms.

There’s also in-depth content on error handling, authentication, chatty APIs, and versioning.

It's a short, well-written 65-page PDF you can skim through quickly. Worth checking out!