Password hashing helper functions generate salt insecurely

[mammothbane]

The password hashing functions depend on math/rand to generate the salt, but that package isn't suitable on its own as a source of cryptographic randomness (rabbit-hole doesn't even seed the default source). Salt generation should depend on crypto/rand instead.

Additionally, restricting the permissible set of values for the salt to just ASCII upper-/lowercase means that the salt only has ~24 bits of effective entropy out of the possible 32.

[michaelklishin]

@mammothbane you are welcome to submit a pull request that addresses both.

[michaelklishin]

I am not a security expert and not sure I correctly understood the comment on ~ 24 bits vs. 32 but I have extended the source range to include digits. If there is a better way to produce a salt value, please submit a PR. I hope this is "secure enough" for most use cases now that we use crypto/rand. And for all others, they can generate a value they need since these functions are just that, convenience helpers.

[michaelklishin]

f34a861 introduced a test failure that seemed legit and therefore was reverted.

[michaelklishin]

My conclusion is this: the salt source characters in the first attempt used some of the characters that differ between URL-safe and standard base64 encoding. This client was using the former while RabbitMQ expects the latter (these values are not passed as part of the URI). The mismatch resulted in 400 Bad Request responses. Since there was a probabilistic component to this (the salt value), sometimes the suite would pass and sometimes it would fail.