Comeonin password hashing library

Yeah, Argon2id is the best option atm. At least, SCrypt is better than BCrypt. In the vast majority of cases it doesn’t really matter since there are much easier ways to get passwords than cracking them.

I wrote about it in the production checklist for Pow with a link to this medium post that details the different popular password hashing options.

Argon2 won the Password Hashing Competition in 2015.

So which hashing algorithm is recommended for systems being designed today?

I’ve read some opinions stating that Argon2 might be better. For instance:

…but I figured I’d ask the Elixir community as well.

In what scenarios would Argon2 should actually be preferred over Bcrypt? The link posted above says “…and offline cracking is in the threat model.” In this context, does “offline cracking” mean the attacker somehow grabs a copy of your database and can attempt to crack the password hashes in it?

Version 5 has been released.

This version is an update based on this issue. Comeonin now provides two behaviours, Comeonin and Comeonin.PasswordHash, which can then be implemented by password hashing libraries.

Together with this update, argon2_elixir and bcrypt_elixir have been updated to version 2.0, and pbkdf2_elixir has been updated to version 1.0.

To update to the new versions, remove :comeonin from the deps function in your mix.exs file, update the hashing library to the latest version, and then edit the hashing functions as shown below:

Comeonin.Argon2.add_hash → Argon2.add_hash
Comeonin.Argon2.check_pass → Argon2.check_pass
Comeonin.Argon2.hashpwsalt → Argon2.hash_pwd_salt
Comeonin.Argon2.checkpw → Argon2.verify_pass
Comeonin.Argon2.dummy_checkpw → Argon2.no_user_verify

For more information see this guide.

If you have any questions / comments, please let me know.

Two things I would like to mention:

First, there is this issue about redesigning Comeonin. I can see arguments for and against the proposed changes, and I would welcome any feedback you might have. As Comeonin is widely used, I want to get as much feedback as I can before making a final decision.

Second, I have set up a patreon page to accept donations. I would like to stress that Comeonin, and the other libraries I maintain, are offered free of charge, but there are times when I cannot spend as much time on them as I would like. If I can receive some financial support, then I will be able to invest more time in their development.

A little explanation of some of the changes that came with version 4 of Comeonin – https://riverrun.github.io/projects/comeonin/2017/09/03/comeonin-v4.html

0.12 will be maintained for the foreseeable future, and it is very stable. It is just that it is not quite as scheduler friendly as the new version.

Making the new version 1.0 is meant to prevent developers updating to the new version by accident.

If you have any further questions, please feel free to ask.

Yupp, I am aware of that. And it is unclear how long at least security relevant patches will flow back to 0.12.

I’m just asking for a rough estimate of 0.12s end-of-life.

If the library is following Semantic Versioning, a jump from 0.x to 1.x indicates that the APIs are not compatible which is indeed the case here.

How long will you provide security backports to pre 1.0? Until OTP 19 fades from main distributions repositories?

It reads as quite a large jump… 0.12 to 1.0

I should have made it clearer that I’m not dropping support for the non-dirty scheduler version.

Version 1.0 supports dirty schedulers.

Version 0.12 is the ‘old’ version, which is still maintained and works fine, so if someone doesn’t want to update to Erlang 20, they can stay on the pre-1.0 version.