Я имею дело с системой PHP, использующей обновленный алгоритм bcrypt (поскольку в базовом алгоритме была известная уязвимость).
Так что PHP password_hash теперь функция генерирует хеш с префиксом $2y$
, как старые (с префиксом $2a
) были уязвимы.
Spring Security’s BCrypt что я использую в другой системе Java генерирует оригинал $2a$
хэши формата, как его базовая реализация (jBCrypt вместо C BCrypt как упоминается в этом посте) не был уязвим к той же атаке.
Проверка PHP-генерирующих хэшей в Spring Security не работает. Есть ли способ проверить сгенерированные PHP хэши с помощью Spring Security?
php > $pwd = password_hash('foo', PASSWORD_BCRYPT, ['cost' => 12]);
php > echo $pwd;
$2y$12$TRc5ZjcmDJ8oFaoR1g7LD.RCxBTUZnGXB66EN9h9rKtNWg.hd7ExK
затем с помощью Java + Spring Security:
@Test
public void decryptsPhpHash() {
boolean result = BCrypt.checkpw("foo", "$2y$12$TRc5ZjcmDJ8oFaoR1g7LD.RCxBTUZnGXB66EN9h9rKtNWg.hd7ExK");
assertThat(result).isTrue();
}
выдает следующую ошибку:
java.lang.IllegalArgumentException: Invalid salt revision
Насколько я знаю, PHP просто изменил символ a на y, чтобы выделить его самому. Только PHP сделал это изменение префикса. Так что, может быть, просто изменение y обратно на a решает эту проблему.
В июне 2011 года была обнаружена ошибка в crypt_blowfish, PHP-реализации BCrypt. Это было неправильное обращение с символами с установленным 8-м битом. Они предложили системным администраторам обновить существующую базу паролей, заменив $ 2a $ на $ 2x $, чтобы указать, что эти хэши плохие (и должны использовать старый сломанный алгоритм). Они также предложили идею иметь crypt_blowfish emit $ 2y $ для хэшей, сгенерированных фиксированным алгоритмом.
Никто другой, включая канонический OpenBSD, не принял идею 2x / 2y. Это изменение маркера версии было ограничено crypt_blowfish.
https://en.wikipedia.org/wiki/Bcrypt
Других решений пока нет …