crypto_password_hash returns an atom

[rrooij]

Should probably be a string as atoms can be easily fetched with current_atom/1

[JanWielemaker]

Thanks for reminding. @triska may prefer adding an option to crypto_password_hash/3 to specify the representation of the hash? Some other predicates use e.g. as(atom), as(string), as(codes), ...

[triska]

The hash in crypto_password_hash/3 is not sensitive information.

Or, phrased differently, if you consider the hash sensitive, then you should choose parameters so that it is no longer sensitive, and apply good practices for choosing passwords!

In this sense, making the hash less accessible would arguably even deter from good practices that solve the root issue (weak passwords, weak parameters).

[JanWielemaker]

In an ideal world I could agree. In practice though, users tend to use relatively weak passwords and re-use them over different domains. You can tell users they shouldn't, but that only helps a little. A password hash allows you to run brute-force attacks on the password without time or max-attempts restrictions and possibly with a lot more hardware than you expected. That does make them a security risk. Of course no user should be able to get access to current_atom/1 in a multi-user setup, but getting access to shared atoms is easier than getting access to volatile data on the stacks.