Ошибка аутентификации Spring после восстановления базы данных

Обновлено: Эта проблема оказалась ошибкой пользователя, пароли были изменены, поэтому хэш никогда не совпадал.

Я использую простую аутентификацию в наборе инструментов Spring 4.2.2, используя DAO, который считывает таблицу базы данных (Postgres) для имени пользователя, пароля и полномочий.

@EnableWebSecurity
@Configuration
class X extends WebSecurityConfigurerAdapter{

    ...
    @Autowired
    private SessionRegistry sessionRegistry;

    @Autowired
    private SessionAuthenticationStrategy sessionAuthenticationStrategy;


    @Override
    protected void configure(HttpSecurity http){
       http.sessionManagement().sessionAuthenticationStrategy(sessionAuthenticationStrategy).maximumSessions(1).sessionRegistry(sessionRegistry).expiredUrl("/login.jsp");

    //presumably unrelated additional code related to matchers, roles, https
    }

    @Bean
    public SessionRegistry sessionRegistry(){
        return new SessionRegistryImpl();
    }

    @Bean
    public SessionAuthenticationStrategy sessionAuthenticationStrategy(){
        return new ConcurrentSessionControlAuthenticationStrategy(sessionRegistry);
    }

    @Bean 
    public PasswordEncoder passwordEncoder(){
       return new StandardPasswordEncoder();   
    }

   ...
}

Недавно я восстановил старую копию базы данных, старая база данных взята с сервера Redhat 6, новая — CentOS 7, хотя на самом деле, поскольку все это поддерживается базой данных, это не должно иметь значения. Часть аутентификации нашего кода совсем не изменилась, но поскольку я восстановил базу данных, несмотря на ввод правильных учетных данных, я получаю

BadCredentialsException: Bad credentials at 
org.springframework.security.authentication.dao.DaoAuthenticationProvider.additionalAuthenticationChecks(DaoAuthenticationProvider.java:98) at
org.springframework.security.authentication.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:165) at   org.springframework.security.authentication.ProvideManager.authenticate(ProviderManager.java:167) at
....  

Остальная часть трассировки стека - это все более стандартные биты трассировки стека spring/catalina/java, ничего нестандартного.

Он не просрочен, я удалил куки, он не отключен....

Этот код не изменился буквально за несколько лет, равно как и таблицы резервной базы данных или библиотеки Spring. Отладка Я могу подтвердить, что правильный пользователь извлекается по имени пользователя, поскольку он идет к аутентификации, что объект пользователя правильно создан с хэшем пароля и полномочиями. Поскольку большая часть этого выполняется поведением классов Spring по умолчанию, я не могу пройти через большую часть кода, как это происходит, поэтому очень сложно определить, где произошли фактические неверные учетные данные и что, черт возьми, могло измениться.

Погуглив, я обнаружил, что у многих пользователей есть проблемы, но почти все они имеют дело с изначально плохой конфигурацией. Это не такая уж проблема, так как этот код работал.

Есть ли какие-либо известные ошибки, связанные с безопасностью Spring, которые я мог бы проверить?

В противном случае, как я могу сортировать это дальше?