Choosing Column Type and Length for Storing Bcrypt Hashed Passwords in Databases

Analysis of Storage Requirements for Bcrypt Hashed Passwords

In database design, storing password hashes is a critical security consideration. Bcrypt, as a widely-used password hashing algorithm, has specific format and length requirements for its output. According to the modular crypt format, a Bcrypt hash typically starts with an identifier like $2a$, followed by a cost parameter and a Base64-encoded salt and encrypted output. This structure determines the total length of the hash.

Length Calculation and Determination

The length of a Bcrypt hash is fixed due to its algorithmic design. Specifically, the complete hash string includes: an algorithm identifier (e.g., $2a$, 3-4 bytes), a cost parameter (2 digits plus $, 3 bytes), and a 53-character Base64-encoded value. This 53-character value further consists of 22 characters for the salt (corresponding to 128 bits) and 31 characters for the encrypted output (corresponding to 184 bits). Thus, the total length is calculated as: identifier length (e.g., 4 bytes) + cost parameter length (3 bytes) + encoded value length (53 bytes) = 60 bytes. This means that for the common $2a$ format, 60 bytes of space should be reserved for storage.

Database Column Type Selection

In relational databases like MySQL, choosing the appropriate column type is crucial. Since Bcrypt hashes contain special characters (such as $ and /) and require exact byte-level comparisons, binary-safe types are recommended. Specifically, CHAR(60) BINARY or BINARY(60) are ideal choices. These types ensure that data is not lost due to character set conversions during storage and that comparison operations rely on byte values rather than character collations. For example, using a regular CHAR type might lead to case-insensitive comparison issues, compromising hash verification security.

Character Encoding and Binary Safety

Binary safety is a core consideration when storing hash values. Bcrypt uses a Base64 encoding alphabet (including ., /, letters, and digits) that differs from the standard Base64, meaning any character re-encoding or truncation must be avoided during storage. By using BINARY types or _bin collations, data can be preserved in its raw byte form, preventing errors caused by character set handling. For instance, in hash comparisons, exact byte-level matching is more secure and reliable than character-level fuzzy matching.

Implementation Examples and Best Practices

In practical applications, developers should always reserve sufficient space to accommodate the full 60-byte hash. Below is a simple SQL representation example, demonstrating how to create a table for storing Bcrypt hashed passwords:

CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(50) NOT NULL,
    password_hash BINARY(60) NOT NULL
);

This design ensures complete storage and efficient retrieval of password hashes. Additionally, regularly reviewing and updating hashing algorithms (e.g., migrating from $2a$ to $2y$) is an important part of maintaining system security.

Performance and Scalability Considerations

Although Bcrypt hash lengths are fixed, storage efficiency in large-scale systems still requires attention. Using BINARY(60) type is generally more efficient than variable-length types, as it avoids length overhead. However, developers should be aware of database version differences, such as improved support for binary types in MySQL 5.5 and above. Furthermore, combining salt storage and cost parameter adjustments can enhance the balance between system security and performance.