nil::crypto3::passhash::bcrypt< BlockCipher > Class Template Reference

Bcrypt is a password hashing scheme originally designed for use in OpenBSD, but numerous other implementations exist. More...

#include <bcrypt.hpp>

+ Collaboration diagram for nil::crypto3::passhash::bcrypt< BlockCipher >:

Public Types

typedef policy_type::cipher_type cipher_type
 

Static Public Member Functions

static bool check (const std::string &pass, const std::string &hash) const
 Takes a password and a bcrypt output and returns true if the password is the same as the one that was used to generate the bcrypt hash. More...
 
static void generate (const std::string &pass, const std::vector< uint8_t > &salt, uint16_t work_factor)
 Takes the password to hash, a rng, and a work factor. The resulting password hash is returned as a string. More...
 

Detailed Description

template<typename BlockCipher = block::blowfish>
class nil::crypto3::passhash::bcrypt< BlockCipher >

Bcrypt is a password hashing scheme originally designed for use in OpenBSD, but numerous other implementations exist.

It has the advantage that it requires a small amount (4K) of fast RAM to compute, which can make hardware password cracking somewhat more expensive. Bcrypt provides outputs that look like this: "$2a$12$7KIYdyv8Bp32WAvc.7YvI.wvRlyVn0HP/EhPmmOyMQA4YKxINO0p2"

Note
Due to the design of bcrypt, the password is effectively truncated at 72 characters; further characters are ignored and do not change the hash. To support longer passwords, one common approach is to pre-hash the password with SHA-256, then run bcrypt using the hex or base64 encoding of the hash as the password. (Many bcrypt implementations truncate the password at the first NULL character, so hashing the raw binary SHA-256 may cause problems. Provided bcrypt implementation will hash whatever values are given in the incoming Container including any embedded NULLs so this is not an issue, but might cause interop problems if another library needs to validate the password hashes.)
Template Parameters
BlockCipher
See also
https://www.usenix.org/legacy/event/usenix99/provos/provos.pdf

Member Typedef Documentation

◆ cipher_type

template<typename BlockCipher = block::blowfish>
typedef policy_type::cipher_type nil::crypto3::passhash::bcrypt< BlockCipher >::cipher_type

Member Function Documentation

◆ check()

template<typename BlockCipher = block::blowfish>
static bool nil::crypto3::passhash::bcrypt< BlockCipher >::check ( const std::string &  pass,
const std::string &  hash 
) const
inlinestatic

Takes a password and a bcrypt output and returns true if the password is the same as the one that was used to generate the bcrypt hash.

Parameters
pass
hash
Returns

◆ generate()

template<typename BlockCipher = block::blowfish>
static void nil::crypto3::passhash::bcrypt< BlockCipher >::generate ( const std::string &  pass,
const std::vector< uint8_t > &  salt,
uint16_t  work_factor 
)
inlinestatic

Takes the password to hash, a rng, and a work factor. The resulting password hash is returned as a string.

Higher work factors increase the amount of time the algorithm runs, increasing the cost of cracking attempts. The increase is exponential, so a work factor of 12 takes roughly twice as long as work factor 11. The default work factor was set to 10 up until the 2.8.0 release. It is recommended to set the work factor as high as your system can tolerate (from a performance and latency perspective) since higher workfactors greatly improve the security against GPU-based attacks. For example, for protecting high value administrator passwords, consider using work factor 15 or 16; at these work factors each bcrypt computation takes several seconds. Since admin logins will be relatively uncommon, it might be acceptable for each login attempt to take some time. As of 2018, a good password cracking rig (with 8 NVIDIA 1080 cards) can attempt about 1 billion bcrypt computations per month for work factor 13. For work factor 12, it can do twice as many. For work factor 15, it can do only one quarter as many attempts.

Due to bugs affecting various implementations of bcrypt, several different variants of the algorithm are defined. As of 2.7.0 Botan supports generating (or checking) the 2a, 2b, and 2y variants. Since Botan has never been affected by any of the bugs which necessitated these version upgrades, all three versions are identical beyond the version identifier. Which variant to use is controlled by the bcrypt_version argument.

The bcrypt work factor must be at least 4 (though at this work factor bcrypt is not very secure). The bcrypt format allows up to 31, but Botan currently rejects all work factors greater than 18 since even that work factor requires roughly 15 seconds of computation on a fast machine.

Parameters
pass
salt
work_factor

The documentation for this class was generated from the following file: