In the current implementation, it is impossible to know if it is our salt that cause a problem or the password.
Maybe you could add an other error ?
pub fn hash_with<'a, IBS>(param: IBS, pass: &str) -> Result<String> where IBS: IntoBcryptSetup<'a> {
let bs = try!(param.into_bcrypt_setup());
let cost = if let Some(c) = bs.cost {
if c < MIN_COST || c > MAX_COST {
return Err(Error::InvalidRounds);
}
c
} else { DEFAULT_COST };
let variant = if let Some(v) = bs.variant {
v
} else { DEFAULT_VARIANT };
let mut salt_buf = [0u8; 16];
if bs.salt.is_some() {
// --------------------- Here --------------------------- \\
try!(bcrypt_hash64_decode(bs.salt.unwrap(), &mut salt_buf)); // This raised an EncodingError for me, but I couldn't figure out where is this error coming from.
\\ ------------------------------------------------------- //
} else {
try!(random::gen_salt_bytes(&mut salt_buf));
}
do_bcrypt(pass, &salt_buf, cost, variant)
}
In case you want to reproduce this bug, here is the salt : svxI11FVz7i+Y9nw11T5/Q==.
This salt was generated with base64::encode.
This is not a bug; the salt svxI11FVz7i+Y9nw11T5/Q== is indeed invalid for bcrypt, since + and = are not valid encoding characters for the format. More details in #6.
In the current implementation, it is impossible to know if it is our salt that cause a problem or the password. Maybe you could add an other error ?
In case you want to reproduce this bug, here is the salt :
svxI11FVz7i+Y9nw11T5/Q==
. This salt was generated with base64::encode.