I also blogged about this topic on blogs.perl.org the other week with some code examples that work a little better [1].
Your code appears to work, but is subtly broken in a few ways. Firstly since you don't return the hash in the "standard" format ("$2a", "$", two digits, "$", salt as 22 base 64 digits, '.', and 31 base 64 digits for the pass), one can't tell what work factor was used to create the hash - making it hard to verify a password. Secondly the salt isn't sufficiently random, there are modules out there that provide more randomness for cryptographic applications such as this.
It's nice to see people blogging about this kind of thing for perl, but it's important that the code is correct.
Have a look at Authen::Passphrase::BlowfishCrypt [1]. it handles a lot of my suggestions automatically and is more suited to your general-case than my code is.
* There's no serious set of test cases. Many Bcrypt implementations were bitten recently when it turned out that they didn't properly handle characters with the high bit set.
* It only ever uses a work factor exponent of 8 which is probably too small for most modern use.
* Even if the password hash specifies a different work factor it will still use 8, and then fail.
* It's not going to interoperate with other implementations for these two reasons.
* The timing of regex's excecution probably leaks information about the salt.
* It uses perl's 'eq' for comparing the strings. The time that this function takes to run is probably dependent on the length of the matching prefix of the two strings. So there's possibly a timing attack enabling an unauthenticated remote attacker to read some of the password hash string. He may need to know the salt, but the salt is not considered a strongly-kept secret. Nate Lawson's blog is a great source on this topic http://rdist.root.org/2010/01/
Your code appears to work, but is subtly broken in a few ways. Firstly since you don't return the hash in the "standard" format ("$2a", "$", two digits, "$", salt as 22 base 64 digits, '.', and 31 base 64 digits for the pass), one can't tell what work factor was used to create the hash - making it hard to verify a password. Secondly the salt isn't sufficiently random, there are modules out there that provide more randomness for cryptographic applications such as this.
It's nice to see people blogging about this kind of thing for perl, but it's important that the code is correct.
[1] http://blogs.perl.org/users/james_aitken/2011/07/safely-stor...