Thank you@chalasr.

I think this is really bad. The user should have control over which algorithm is used.

Implementation wise, it's possible to usesodium_crypto_pwhash instead, as I've discussed with@chalasr extensively about this.

@teohhanhui Allowing to specify the algorithm involves to rely on implementation details and to make strong assumptions that may be wrong at some point or don’t fit for all platforms. The result felt a bit hackish tbh.
Consideringhttps://github.com/jedisct1/libsodium-php/issues/194

sodium_crypto_pwhash_str() uses the best algorithm available in the currently installed version of libsodiumfor the current platform.
It can be Argon2i, Argon2id, or something else depending on the platform (Argon2 is currently not a good fit for constrained environments and WebAssembly). You shouldn’t assume that it is a specific algorithm.

Our role as a framework is to always provide the most secure alternative, that is whatsodium_crypto_pwhash_str() does.
Also@paragoniedoes the same. Given the strong knowledge they have on this topic, I think we'd better not try to reinvent the wheel.

My plea to the Symfony team: please hold your horses on the deprecation of using specific password hashing algorithms. This deserves more input / feedback from the community, as it entails taking away control from the application developer.

Our role as a framework is to always provide the most secure alternative, that is what sodium_crypto_pwhash_str() does.

Of course, it's good to havesodium_default /php_default password encoders available. But the developer should still be able to choose a specific algorithm, depending on their needs.

I will try working on implementations that usesodium_crypto_pwhash.

Honestly, I think we should adopt the recommended practice and stop allowing ppl to choose the algo. Sticking to one algowill be broken in the future, because that's the life of hash algos. I'm all for deprecating the existing encoders that are bound to one algo.

If we're taking that route, then it should be done similar to this? So that passwords using old algorithms could be transparently re-hashed (upon password validation and detecting that a rehash is needed). It'll be invaluable for so many projects. (But IMO, actually the developer should still be able to configure which algorithms should be used.)

https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/reference/html5/#pe-dpe
https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/api/org/springframework/security/crypto/password/DelegatingPasswordEncoder.html
https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/api/org/springframework/security/crypto/factory/PasswordEncoderFactories.html#createDelegatingPasswordEncoder--

I see there's#30914

Hi,

I think this might cause a problem when I hash passwords on the machine with different Argon implementation and validate them on another one. I run app in php 7.2 on Debian but sometimes I need to run CLI command which add user from the machine which runs on 7.3 on MacOS with the different sodium library.

Means that I $passwordEncoder->isPasswordValid(...) will not validate the password when I generated on different machine?

I agree this might be a problem. Yet the outcome is ok: you won't be able to log in. I can't imagine how we could do better while still providing state of the art security practices (always using the best possible hash algo)

But it's at least forward-compatible, right?