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
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;
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.
In reply to Re: Adjust bcrypt cost to prevent future password hash attacks
by Anonymous Monk
in thread Adjust bcrypt cost to prevent future password hash attacks
by andreas1234567
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |