Understanding bcrypt Hashing: Why Passwords Cannot Be Decrypted and Proper Verification Methods

Nov 21, 2025 · Programming · 12 views · 7.8

Keywords: bcrypt algorithm | password hashing | salt security

Abstract: This article provides an in-depth analysis of the bcrypt hashing algorithm, clarifying the fundamental differences between hashing and encryption. Through detailed Perl code examples, it demonstrates proper password hashing and verification workflows, explains the critical roles of salt and work factor in password security, and offers best practice recommendations for real-world applications.

Fundamental Differences Between Hashing and Encryption

In the field of cryptography, hashing and encryption represent two fundamentally distinct technical concepts. Hash functions are one-way mathematical transformations that map input data of arbitrary length to fixed-length output values, a process that is irreversible. Encryption algorithms, in contrast, are two-way operations that convert plaintext to ciphertext using specific keys, and the same keys can be used to restore the ciphertext to its original plaintext form.

Working Principles of the bcrypt Algorithm

bcrypt is an adaptive hash function based on the Blowfish cipher, specifically designed for password hashing. Its core advantage lies in the built-in work factor (cost factor), which makes the computational cost of brute-force attacks increase over time. The standard format of a bcrypt hash is: $2a$08$salt$hashed_password, where 2a indicates the algorithm version, 08 represents the work factor (2^8 iterations), and salt is a 22-character Base64-encoded salt value.

Correct Methods for Password Verification

Since bcrypt is a hash function rather than an encryption algorithm, there is no possibility of "decrypting" hash values. The correct password verification process is as follows: when a user submits a password, the system performs bcrypt hashing on the input password using the same salt and work factor, then compares the result with the stored hash value. If the two hash values match exactly, verification succeeds.

sub check_password {
    my ($plain_password, $hashed_password) = @_;
    
    # Extract salt using regular expression
    if ($hashed_password =~ m!^\$2a\$\d{2}\$([A-Za-z0-9+\\.]{22})!) {
        my $salt = $1;
        # Recompute hash with same salt
        my $new_hash = encrypt_password($plain_password, $salt);
        # Compare hash values
        return $new_hash eq $hashed_password;
    } else {
        return 0;  # Format mismatch
    }
}

Importance of Salt Values

Salt is a critical security element in password hashing. It generates unique random values for each password, ensuring that even if two users employ the same password, their hash values will be completely different. This effectively prevents rainbow table attacks because attackers cannot precompute hash values for common passwords. In bcrypt implementations, salt is typically created using cryptographically secure random number generators.

sub salt {
    # Generate 16-byte random data and Base64 encode
    return Crypt::Eksblowfish::Bcrypt::en_base64(
        Crypt::Random::makerandom_octet(Length=>16)
    );
}

Security Significance of Work Factor

The work factor (or cost factor) determines the number of iterations in bcrypt hash computation. Higher factor values significantly increase computation time, thereby effectively resisting brute-force attacks. As hardware performance improves, it is recommended to periodically adjust the work factor to maintain security levels. For example, gradually increasing from the initial 08 (256 iterations) to 12 (4096 iterations).

Practical Application Recommendations

In production environments, the following best practices are recommended: use sufficiently high work factors (currently recommended at least 12), ensure the randomness and uniqueness of salt values, regularly update hashing algorithms to address new security threats, and implement appropriate rate limiting to prevent online brute-force attacks. Never log raw passwords or hash values in logs or error messages.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.