Re: Adjust bcrypt cost to prevent future password hash attacks

I'm using a different bcrypt module, Crypt::Eksblowfish::Bcrypt, and am observing that instead of a hex digest, it stores both the settings and the salt in the output hash:

length = 11
  $2a$11$WUHhXETkX0fnYkrqZU3ta.SjqJkrtBHwUGTHlTfGO1BINxczZnBJm
length = 12
  $2a$12$WUHhXETkX0fnYkrqZU3ta.D8cEIQdqzSrGG5wFTandtdP9Ypqzu0W
[download]

Therefore, your JSON-like storage should not be needed. This is the code I was using:

use Time::HiRes 'time';
use Crypt::Eksblowfish::Bcrypt qw(bcrypt en_base64);

sub _salt() {
        return en_base64('abcdefghijklmnop');
}

my $cost = sprintf("%02d", $ARGV[0]);
my $settings = join( '$', '$2a', $cost, _salt() );

my $st = time();
print bcrypt("password", $settings), "\n";
printf "took %i milliseconds\n", (time() - $st) * 1000;
[download]

I suspect a cost of 11-14 is good enough to deter brute force and even some dictionary attacks on today's hardware, while not bogging down your server -- depending of course on the security requirements and the amount and frequency of users needing to log in.

Comment on Re: Adjust bcrypt cost to prevent future password hash attacks Select or Download Code

Replies are listed 'Best First'.
Re^2: Adjust bcrypt cost to prevent future password hash attacks by andreas1234567 (Vicar) on Jun 12, 2012 at 13:03 UTC
I'm using a different bcrypt module, Crypt::Eksblowfish::Bcrypt, According to the documentation, Digest::Bcrypt is mostly a wrapper around Crypt::Eksblowfish::Bcrypt. .. it stores both the settings and the salt in the output hash Does that mean you can deduce the cost from the output hash alone? In order to adjust the cost over time, one either need to store the cost or be able to compute it (e.g. from the output hash). -- No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]	[reply]
Re^3: Adjust bcrypt cost to prevent future password hash attacks by Anonymous Monk on Jun 12, 2012 at 13:30 UTC
Does that mean you can deduce the cost from the output hash alone? In order to adjust the cost over time, one either need to store the cost or be able to compute it (e.g. from the output hash). I believe so. It's stored right after the $2a$ . The output hash, by the looks of it, is similar to the way passwords are stored in Unixes -- and this is no surprise since bcrypt came from the OpenBSD guys. The format is: `$cryptomethod$length$salt$password`, although anything after $cryptomethod$ is roughly freeform and parsed by the method (i.e. bcrypt) itself. I'm not sure about what sort of hash Digest::Bcrypt is supposed to return, but it looks nothing like the raw Eksblowfish version. Personally, I would not trust this module if I cannot get an output similar to the `crypt(3)` C function from it.	[reply] [d/l] [select]