But what prevents you from adjusting the Crypt::Eksblowfish::Bcrypt result?

my $user = "admin";
my $password = "hunter2";

sub rnd_salt { local $/ = \16; open my $fh, '</dev/urandom'; scalar <$
+fh> }

use Crypt::Eksblowfish::Bcrypt qw(bcrypt en_base64);

my $param = '$2a$05$' . en_base64(rnd_salt());
my $pass = bcrypt($password, $param);
$pass =~ s/^\$2a/\$2y/;

print "$user:$pass";
[download]

Update. As far as I can tell, "2x" and "2y" disambiguate between buggy and non-buggy bcrypt implementations. The "2a" in Eksblowfish module is the non-buggy variant.

Update3. Looking further, it appears the current Crypt::Eksblowfish::Bcrypt (version 0.009) produces the non-buggy hashed output as per original spec. The crypt_blowfish implementation/spec for the "2a" hash, however, has meanwhile changed. There is now a (very small) subset of passwords for which the "2a" and "2y" hashes diverge. I must say, this whole affair does not inspire much confidence. My advice is not to use, and not to support, any of the qw(2a 2x 2y) labels, where not unavoidable. The 2a is just fubar, the 2x broken, and 2y redundant. Use the new designation "2b", which incidentally is equivalent to "2y".

Uh-oh. There's also this "feature" that affects passwords longer than 72 characters (fixed in "2b"). Crypt::Eksblowfish::Bcrypt gets that one right, too.

Summary: the only thing Crypt::Eksblowfish::Bcrypt needs to do is change the hash label from "2a" to "2b", and it's good.