</>KemmerApp

Mysql

What data type to use for hashed password field and what length

25 September 2026 · 6 min read

What data type to use for hashed password field and what length

Storing user passwords securely is paramount in today’s digital landscape. Choosing the right data type and length for your hashed password field is a crucial aspect of this security. A weak configuration can leave your users vulnerable to attacks, potentially compromising sensitive information. This post delves into the best practices for selecting the optimal data type and length for storing hashed passwords, ensuring robust protection against unauthorized access.

Choosing the Right Data Type

The data type you select directly impacts the security and efficiency of password storage. While VARCHAR might seem suitable at first glance, it’s not the ideal choice for hashed passwords. Instead, opt for CHAR or BINARY data types. CHAR offers fixed-length storage, ensuring consistent performance regardless of the hash length. BINARY provides a more secure storage mechanism specifically designed for binary data, like hashed passwords. This helps prevent potential encoding issues and enhances overall security.

For instance, if you’re using SHA-256, which produces a 256-bit hash, a BINARY(32) or CHAR(64) would be appropriate. The 32 in BINARY(32) represents 32 bytes (256 bits), while CHAR(64) represents 64 characters, as each hexadecimal character in the hash represents 4 bits (64 4 = 256).

Selecting the appropriate data type not only strengthens your security posture but also optimizes database performance. By utilizing a data type specifically designed for binary data, you can streamline data retrieval and processing.

Determining the Appropriate Length

The length of your hashed password field should accommodate the maximum output length of your chosen hashing algorithm. Using SHA-256, which produces a 256-bit hash, requires a field length of at least 32 bytes if storing the raw binary or 64 characters if storing the hexadecimal representation. Avoid truncating the hash, as this significantly weakens its security. Truncating a hash makes it easier for attackers to crack using techniques like rainbow table attacks or brute-force methods.

For example, if you are using bcrypt, which has a variable output length, ensure your field length can accommodate the maximum possible length. This proactive approach guarantees the integrity of the hash and reinforces your security measures.

Remember, a longer hash generally offers stronger security. Always consult the documentation for your specific hashing algorithm to determine the recommended length and adjust your database field accordingly.

Why Hashing is Essential

Hashing is a one-way function that transforms plaintext passwords into unique, irreversible strings. This process makes it computationally infeasible to retrieve the original password from the stored hash. Even if your database is compromised, the hashed passwords remain protected, preventing attackers from gaining direct access to user accounts. Learn more about password security best practices.

Hashing is a fundamental security practice that safeguards user credentials and protects against unauthorized access. Implementing a robust hashing algorithm is crucial for maintaining the integrity and confidentiality of sensitive user data.

Choosing a strong hashing algorithm, like bcrypt, scrypt, or Argon2, further enhances the security of your password storage. These algorithms are designed to be resistant to common cracking techniques, adding an extra layer of protection against brute-force and rainbow table attacks. For more in-depth information, refer to the National Institute of Standards and Technology (NIST) guidelines on password security.

Salting and Peppering: Enhancing Password Security

Salting and peppering are techniques used to strengthen hashed passwords. Salting involves adding a unique random string to each password before hashing, while peppering adds a secret string to all passwords before hashing. These techniques make it significantly more difficult for attackers to crack passwords, even if they obtain a database of hashed passwords. They also mitigate the risk posed by rainbow table attacks.

Infographic Placeholder: Illustrating the Salting and Peppering Process

  • Always use a strong hashing algorithm like bcrypt, scrypt, or Argon2.
  • Implement salting and peppering to further enhance security.
  1. Choose a strong hashing algorithm.
  2. Determine the appropriate data type and length.
  3. Implement salting and peppering.

By combining these methods, you can significantly strengthen your password security and protect user accounts from unauthorized access. Remember to store salts securely and never reuse salts across multiple passwords.

Consider using a password management tool to generate and store strong, unique passwords for different accounts. This helps users maintain good password hygiene and minimizes the risk of credential compromise.

FAQ

Q: What if I’m using an older database system?

A: Even older database systems often support the CHAR and BINARY data types. Prioritize using these data types whenever possible for optimal security. If you’re facing limitations, consult the documentation for your specific database system to determine the best approach.

Choosing the correct data type and length for your hashed password field is a fundamental step in securing user data. By following the best practices outlined in this post – using appropriate data types like CHAR or BINARY, selecting adequate length for your chosen hashing algorithm, implementing salting and peppering, and leveraging strong hashing algorithms – you can significantly enhance the security of your application and protect your users from potential threats. Start prioritizing password security today and build a more secure online environment for everyone. Explore additional resources on OWASP and NIST for further guidance on password security best practices.

Question & Answer :
I’m not sure how password hashing works (will be implementing it later), but need to create database schema now.

I’m thinking of limiting passwords to 4-20 characters, but as I understand after encrypting hash string will be of different length.

So, how to store these passwords in the database?

Update: Simply using a hash function is not strong enough for storing passwords. You should read the answer from Gilles on this thread for a more detailed explanation.

For passwords, use a key-strengthening hash algorithm like Bcrypt or Argon2i. For example, in PHP, use the password_hash() function, which uses Bcrypt by default.

$hash = password_hash("rasmuslerdorf", PASSWORD_DEFAULT);

The result is a 60-character string similar to the following (but the digits will vary, because it generates a unique salt).

$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a

Use the SQL data type CHAR(60) to store this encoding of a Bcrypt hash. Note this function doesn’t encode as a string of hexadecimal digits, so we can’t as easily unhex it to store in binary.

Other hash functions still have uses, but not for storing passwords, so I’ll keep the original answer below, written in 2008.

It depends on the hashing algorithm you use. Hashing always produces a result of the same length, regardless of the input. It is typical to represent the binary hash result in text, as a series of hexadecimal digits. Or you can use the UNHEX() function to reduce a string of hex digits by half.

  • MD5 generates a 128-bit hash value. You can use CHAR(32) or BINARY(16)
  • SHA-1 generates a 160-bit hash value. You can use CHAR(40) or BINARY(20)
  • SHA-224 generates a 224-bit hash value. You can use CHAR(56) or BINARY(28)
  • SHA-256 generates a 256-bit hash value. You can use CHAR(64) or BINARY(32)
  • SHA-384 generates a 384-bit hash value. You can use CHAR(96) or BINARY(48)
  • SHA-512 generates a 512-bit hash value. You can use CHAR(128) or BINARY(64)
  • BCrypt generates an implementation-dependent 448-bit hash value. You might need CHAR(56), CHAR(60), CHAR(76), BINARY(56) or BINARY(60)

As of 2015, NIST recommends using SHA-256 or higher for any applications of hash functions requiring interoperability. But NIST does not recommend using these simple hash functions for storing passwords securely.

Lesser hashing algorithms have their uses (like internal to an application, not for interchange), but they are known to be crackable.