Added in method to hash using a base64 encoded salt

[jhobern]

I found myself writing an application that received a salt that was already base64 encoded, and I needed to convert it into a byte array in order to hash it. This seemed a bit redundant, especially because there already was functionality to convert a base64 encoded salt into a byte array salt embedded in the verify function, so I pulled it out. I figured it might be useful to someone else too!

[Keats]

Is there an equivalent in other language libraries?

[jhobern]

Is there an equivalent in other language libraries?

The javascript bcrypt implementation hashes using a salt string that is ${version}${cost}${base64_encoded_salt}, e.g. "$2a$13$RsVdDAOAx7qc5DVABxfQRu". This is not exactly the same as using the base64_encoded_salt directly, but is very similar.

https://github.com/kelektiv/node.bcrypt.js/blob/master/bcrypt.js#L89

[yo-main]

This would definitively have been useful to me !

But I wonder if it wouldn't make sense to be able to hash a password given the full encoded string ($2a$13$RsVdDAOAx7qc5DVABxfQRu) ?

This is something that is doable in python as well (and it uses an implementation made in rust, and rely on your library ^^ https://github.com/pyca/bcrypt/blob/main/src/_bcrypt/src/lib.rs#L16)

I had this need and found it not optimal to let the user parse and decode the above string when the rust-bcrypt library has all utilities to do it anyway. At the very least would it make sense to make the function split_hash public ?

[jhobern]

At the very least would it make sense to make the function split_hash public ?

Agreed that split_hash should be public at a minimum

[Keats]

I think there's no issues making split_hash public

[Keats]

HashParts::from_str is public without us needing to expose the function directly. No need to make split_hash itself public in the end.