You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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), ...
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).
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.
Activity
JanWielemaker commentedon Dec 4, 2019
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 commentedon Dec 4, 2019
The hash in
crypto_password_hash/3is 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 commentedon Dec 4, 2019
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.