In practice, I suspect that either the bindings for Argon2/scrypt don't exist or aren't easily adoptable given their use of ColdFusion. They do exist in Python.
Either way, it seems like a sub-optimal decision.
they should be adopting Argon2
It currently isn't ready in large production. Efforts to stabilise the API are being spearheaded by someone apparently outside the project[1]. If you're reading this @lucab, thank you.
In the meantime, my Ruby bindings have been broken on three separate occasions due to API changes. You could easily say "Don't track master", but the one release has a tag of 20151206, and it's just an arbitrary a tag as any particular commit id. There is no branch from which you could apply "bugfix only" updates.
Two separate commits broke compilation. This commit[2] was a shambles.
Most importantly, they have commits going in two days ago that change the test vectors[3]. That means if you update your library, verifying existing passwords breaks. The hash identifier doesn't change ( in the way that bcrypt had $2, then changed it to $2a then $2y when they changed the algorithm) which means you can't just write an "upgrade hash" function. I can't find any documentation relating to this change.
It's important to note that none of this means your passwords are easily broken, or that it's insecure, which is the implication I often see thrown around when discussing Argon2 being "new".
[0] https://github.com/P-H-C/phc-winner-argon2/commits/master?au... [1] https://github.com/P-H-C/phc-winner-argon2/issues/61 [2] https://github.com/P-H-C/phc-winner-argon2/issues/87 [3] https://github.com/P-H-C/phc-winner-argon2/commit/37e031213e...
(Also last I looked Python has no good scrypt bindings.)
https://paragonie.com/blog/2016/02/how-safely-store-password... https://news.ycombinator.com/item?id=11118720