always "Bad credentials" though password is correct

[BernardA]

Symfony version(s) affected: 4.3.5

Description
It always throws bad credential exception even though password is correct.
This seems to be related to this issue.

This is a Symfony API-Platform back-end with Gatsby on the front-end, FIY. It was working fine and the only thing I can think I did was to install Vich uploader bundle. The issue started after that. Though I reversed back to the situation before that change, the problem persisted.

Then, checking the logs I noticed the deprecation of the password encoder and applied the new recommendation, like so:

/config/packages/security.yaml

      encoders:
         App\Entity\User:
            algorithm: auto

Users are being loaded from fixtures and password encoded as follows:

     UserPasswordEncoderInterface $passwordEncoder,

        $user->setPassword(
            $this->passwordEncoder->encodePassword(
                $user,
                $userFixture['password']
            )
        );

I did register an user from the front-end and it also had the same issue.

This is how an encoded password looks like on the db:

   $argon2id$v=19$m=65536,t=4,p=1$DjdHrgs64e45ByyMz4H

How to reproduce

Complete code in this repository.

Possible Solution

Additional context
The error log shows that the issue is specifically the password.

  [2019-10-25 08:38:19] security.INFO: Authentication request failed. {"exception":"[object] (Symfony\\Component\\Security\\Core\\Exception\\BadCredentialsException(code: 0): Bad credentials. at /Users/user/Sites/quiamo-api/vendor/symfony/security-core/Authentication/Provider/UserAuthenticationProvider.php:85, Symfony\\Component\\Security\\Core\\Exception\\BadCredentialsException(code: 0): The presented password is invalid. at /Users/user/Sites/quiamo-api/vendor/symfony/security-core/Authentication/Provider/DaoAuthenticationProvider.php:58)"} []

[BernardA]

Checking further I found where the error is happening:

On /vendor/symfony/security-core/Authentication/Provider/DaoAuthenticationProvider.php

   protected function checkAuthentication(UserInterface $user, UsernamePasswordToken $token)
{
    $currentUser = $token->getUser();
    if ($currentUser instanceof UserInterface) {
        if ($currentUser->getPassword() !== $user->getPassword()) {
            throw new BadCredentialsException('The credentials were changed from another session.');
        }
    } else {
        if ('' === ($presentedPassword = $token->getCredentials())) {
            throw new BadCredentialsException('The presented password cannot be empty.');
        }
        var_dump($user->getPassword());
        var_dump($presentedPassword);
        if (!$this->encoderFactory->getEncoder($user)->isPasswordValid($user->getPassword(), $presentedPassword, $user->getSalt())) {
            throw new BadCredentialsException('The presented password is invalid.');
        }
    }
}

This will output to Postman:

   string(50) "$argon2id$v=19$m=65536,t=4,p=1$DjdHrgs64e45ByyMz4H"
   string(10) "Secret123#"
  {
      "code": 401,
      "message": "Bad credentials."
  }

The plain password is correct as you may check in the fixtures script and the encoded password also correspond to the one from the database for that user.

So, the $encoderFactory->getEncoder seems to be getting an encoder that does not correspond to the one used to encode the user password in the first place.

[akshay-achar]

@BernardA : Can you try this. https://stackoverflow.com/questions/47675301/token-was-deauthenticated-after-trying-to-refresh-it.
We faced the same issue and then we implements the EqutableInterface for the User details Model.

[BernardA]

Thanks @akshayachar2011 but that did not help. Still getting "Bad credentials" no matter what.

[linaori]

I would suggest to use a different authenticator, such as guard. The Dao variant (form_login) is fragile, complex and the opposite of flexible.

[BernardA]

As I mentioned above, this is an API-Platform app. Specifically it uses the Lexik JWT bundle for authorization.
My configuration for login follows the one recommended by the bundle.

I do use guard for social login - Google.

/config/packages/security.yaml

   security:
# https://symfony.com/doc/current/security.html#where-do-users-come-from-user-providers
encoders:
    App\Entity\User:
        algorithm: auto
providers:
    database:
        entity:
            class: App\Entity\User
            property: email
firewalls:
    dev:
        pattern: ^/(_(profiler|wdt)|css|images|js)/
        security: false
    refresh:
        pattern:  ^/api/token/refresh
        stateless: true
        anonymous: true
    login:
        pattern:  ^/api/login
        stateless: true
        anonymous: true
        json_login:
            check_path:               /api/login_check
            success_handler:          lexik_jwt_authentication.handler.authentication_success
            failure_handler:          lexik_jwt_authentication.handler.authentication_failure
    api:
        pattern: ^/api
        stateless: true
        anonymous: true
        guard:
            authenticators:
               # - lexik_jwt_authentication.jwt_token_authenticator
                - App\Security\TokenAuthenticator
                - app.google_login_authenticator
            entry_point: App\Security\TokenAuthenticator
        user_checker: App\Security\UserEnabledChecker
access_control:
    - { path: ^/login,     roles: IS_AUTHENTICATED_ANONYMOUSLY }
    - { path: ^/admin,     roles: ROLE_SUPERADMIN }
    - { path: ^/api/token/refresh, roles: IS_AUTHENTICATED_ANONYMOUSLY }
    - { path: ^/api,       roles: IS_AUTHENTICATED_ANONYMOUSLY }
role_hierarchy:
    ROLE_PROVIDER: ROLE_USER
    ROLE_ADMIN: [ROLE_PROVIDER, ROLE_EDITOR]
    ROLE_SUPERADMIN: ROLE_ADMIN

[BernardA]

@linaori Just for the heck of it I set up a custom guard authenticator, replacing the one from Lexik bundle.

The result was the same. Bad credentials.

This is the set up in brief.

/ config/packages/security.yaml

     login:
        pattern:  ^/api/login
        stateless: true
        anonymous: true
        json_login:
            check_path:               /api/login_check
            # success_handler:          lexik_jwt_authentication.handler.authentication_success
            # failure_handler:          lexik_jwt_authentication.handler.authentication_failure
        guard: 
            authenticators: 
                - app.google_login_authenticator
                - app.login_check_authenticator
            entry_point: app.login_check_authenticator

The checkCredentials method of the custom guard authenticator below will return false event though the dump of the password shows the correct password.

/App/Security/LoginCheckAuthenticator.php

  ....
public function checkCredentials($credentials, UserInterface $user)
{
    var_dump($credentials['password']);
    $encoder = $this->container->get('security.password_encoder');
    return $encoder->isPasswordValid($user, $credentials['password']);
}

[xabbuh]

@BernardA Can you debug if the user password encoder uses the right encoder based on your user class?

[BernardA]

Not sure how to go about that, meaning that I have no idea how to do it. Please specify how.

[xabbuh]

You can use a debugger like Xdebug or add some dump() calls to get more insights.

[BernardA]

Sure, I did that. That's how I found out where the problem was and pointed out above.