Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Okta had an interesting security incident. If the username was above 52 characters, then ANY password would be sufficient for logging in. If the username was 50 characters, then it would be only two. In Okta, the password hash included the concatenation of the userId, username and password.

Why did this happen? The hashing function BCrypt! In BCrypt, there is a limit to the size of the input to 72 characters. Since the user ID and username were included, it was possible to go above this. In some libraries, this would lead to a silent truncation of the data. With how much data Okta was using besides the password, this led to the entire password being truncated.

The author was curious about why the library even allowed this in the first place. A simple check on the input length would be sufficient in the library for preventing this from happening. They evaluated several implementations of libraries in different languages, all of which handled this case differently. Some errored out and some silently truncated the data. Why the truncation? They were conforming to the BSD implementation from years ago!

My personal favorite part of the article is the end. The author goes into Secure API Design. Recently, this has become a bigger concern of mine in my job so it was interesting to see these come out.

The first point is Don’t let the people use your API incorrectly. It should explicitly reject invalid input in order to prevent errors like this. If the functionality is required, then gate it behind a feature flag or unsafe variant of the function.

The next point was Be predictable. Good API design should be intuitive and obvious. Of course, this is subjective but we can use some common sense here.

No ego is the next one. Expecting users to read every bit of documentation or fully understand the implementations is totally unreasonable. Making systems easy to use for novice users should be the goal, with more advanced functionality being added to the more advanced ones. Good input validation goes a long way here.

The final point of note is Be Brave. To the authors point, be the new solution that is better. It's easy to fallback onto old implementations since it's always been there. Do something to make the world a better place.

Overall, an interesting read that further evaluates the Okta issue. I enjoyed the parts about secure API design the most that used Okta as a case study.