Understanding Okta's Security Issue with bcrypt

Introduction

With more data being stored online every day, securing user passwords is essential. bcrypt is one of the most popular ways to hash (or "scramble") passwords so that they’re safe from hackers. However, using bcrypt incorrectly can leave your app vulnerable, as shown recently when the security company Okta experienced an authentication vulnerability due to bcrypt's limits.

In this post, we’ll break down what went wrong, explain why bcrypt’s limitations matter, and go over how to use bcrypt safely in your applications.

The Okta Vulnerability: What Happened?

Recently, Okta faced a security issue because of how bcrypt handles long strings. bcrypt only hashes the first 72 characters of any input. If a username or password is longer than 72 characters, bcrypt simply ignores the extra characters.

In Okta’s case, usernames longer than 52 characters were not handled correctly, letting users log in with any password if they used one of these long usernames. This highlights the importance of being aware of bcrypt’s limits.

Why Does bcrypt Limit Input Length?

bcrypt has a 72-character limit because it’s designed to be fast and secure for hashing shorter strings, like passwords. This limit can cause problems if your input isn’t carefully checked:

• Truncated Inputs: Only the first 72 characters are used, so longer inputs get cut off.

• Unexpected Matches: If two usernames or passwords have the same first 72 characters, bcrypt will produce the same hash, leading to possible security risks.

Understanding and respecting this limit is key to using bcrypt effectively.

How to Use bcrypt Safely: Essential Tips

1. Set Limits on Username and Password Length

• Limit usernames to a safe length, such as 32 characters, to ensure they stay well below bcrypt’s 72-character cap.

• Limit passwords to a reasonable length (64 characters or less). This prevents bcrypt from accidentally ignoring characters in long passwords.

2. Only Use bcrypt for Passwords

• bcrypt is designed for passwords, not for other sensitive strings, tokens, or long inputs. For non-password data, look for hashing options that handle longer strings safely.

3. Double-Check Your Authentication Code

• Regularly review your authentication code to make sure it’s using bcrypt correctly. If you’re part of a team, code reviews can catch mistakes that could lead to security issues.

4. Know When to Use Alternatives

• For cases where you need to hash longer data, consider algorithms like PBKDF2 or Argon2, which can handle longer strings without limits. These are also secure and designed for password hashing.

5. Stay Updated on Security Practices

• Security methods change over time. Regularly check for updates to bcrypt and password-hashing recommendations to keep your users safe.

  ---

  Conclusion

  bcrypt is an excellent tool for hashing passwords, but its 72-character limit can cause issues if you’re not careful. By limiting input lengths, only using bcrypt for passwords, and staying aware of its quirks, you can keep your authentication system secure.

  In security, small steps make a big difference. Following these tips will help you avoid common bcrypt pitfalls and build safer applications.

  ---

  Reference

• https://trust.okta.com/security-advisories/okta-ad-ldap-delegated-authentication-username/