[security-bundle recipe] Use less resource-intensive password hasher for `test` environment

[maks-rafalko]

As explained in different blog posts (here, here), and also in the docs - default password hasher (auto) consumes a lot of resources and takes too much time, especially when it's executed thousands of times in functional tests.

From https://symfony.com/doc/current/security/passwords.html#configuring-a-password-hasher

Hashing passwords is resource intensive and takes time in order to generate secure password hashes. In general, this makes your password hashing more secure.

In tests however, secure hashes are not important, so you can change the password hasher configuration in test environment to run tests faster:

# config/packages/test/security.yaml
password_hashers:
    # Use your user class name here
    App\Entity\User:
        algorithm: plaintext

So, what do you think to update an official recipe and in addition to config/packages/security.yaml add one more file - config/packages/test/security.yaml with the code above?

This will help many developers creating new projects to not waste time with functional tests.

Related to

• docs: Add information about how to significantly improve the test suite api-platform/docs#1472
• https://maks-rafalko.github.io/blog/2021-11-21/symfony-tests-performance/#using-more-simple-password-hasher

Thank you.

[chalasr]

Sounds good 👍. The class should be Symfony\Security\Core\User\PasswordAuthenticatedUserInterface

[kbond]

I also recommend this with Foundry. One very minor note about plaintext: you cannot functionally test password migrations. During some experimentation, I found the speed between plaintext and the lowest auto work factor to be negligible. I also prefer to stay "as close to production as possible" with my tests.

[dunglas]

Maybe could we add a test-hasher designed to be a no-op but supporting all features including (faked) password migration?

[kbond]

@dunglas do you mean test-hasher as a wrapper for auto that just sets the work factor as low as possible?

[dunglas]

It could be that, or just something that does nothing to be as fast as possible, but implements all the common interfaces.

[kbond]

Ok, I'd definitely prefer it to do nothing at all. I'm trying to figure out how a password migration could be tested though. In my test suite I manually hash a user's password with bcrypt, log them in, then ensure it's now the best algo.

[stof]

password migration is not limited to auto. The target of a migration could be an older (less resource intensive) algorithm too.
What is necessary is a target hasher that is able to implement needsRehash in a meaningful way.

However, it is true that older algorithms implemented in the core don't provide that (as they are not really meant to be a target of a migration, and the complexity would have to be higher than for modern algorithms which are implemented through APIs exposing that logic already)