Почему реализации `` PasswordEncoder`` используют жестко закодированный UTF-8 в Spring Security 5.x в качестве входных данных?

Question

Я только что наткнулся на неожиданное поведение Spring Security 5.x: предоставленные реализации PasswordEncoder используют кодировку UTF-8 для данных, которые должны быть хешированы жестко закодированным способом (примеры: MessageDigestPasswordEncoder , BCrpyt ).Таким образом, нет ни способа внедрить другую кодировку, ни каким-либо образом настроить это поведение.

Теперь мне любопытно узнать, почему было принято это проектное решение?(И я не сомневаюсь, что это было глубокое решение; мы все равно говорим о весне!)

Я ничего не обнаружил в их официальной ссылке , и при этомони говорят что-то в своих API документах .Я бы ожидал найти больше информации об этом дизайнерском решении, если честно.И если не как обоснование , то как минимум явная документация об этом факте.(Поиск, конечно, немного сложен, так как у нас есть семантическая коллизия, когда дело доходит до кодирования вопросов, касающихся хеширования ... возможно, я действительно это упустил?)

Моя первоначальная проблема заключалась в том, что мне приходилось иметь дело с устаревшей системой, где хэш пароля создается с ISO-8859-1 CP-1252 в качестве основы для хеширования.и поэтому совпадение в моем приложении Spring Boot 2 не удалось.Конечно, я могу решить эту проблему, просто позволив изменить устаревшую систему - мне очень повезло, что мне не нужно поддерживать устаревшее приложение ?.

Но я все еще задаюсь вопросом, почему easy решение (определение соответствующей кодировки LATIN1 для кодировщика в Spring а-ля spring.security.crypto.encoding=cp-1252) здесь не работает.

Это, кажется, противоречит всему остальному в Spring, где вы можете настроить практически все, если вам нужно или нужно.Вот почему я задаю этот вопрос здесь.

Редактировать: Я только что узнал, что MySQL кроме UTF-8 также не смог назвать их LATIN1 кодирование в правильном направлении: CP-1252 (или WINDOWS-1252 , если вы предпочитаете).Поэтому мое предположение о кодировке ISO-8859-1 было неверным.В конце концов, это не влияет на саму проблему!

Answer 1

Во-первых, я должен отметить, что на умозрительные вопросы может быть сложно ответить.Несмотря на то, что я часто зацикливаюсь на проекте Spring Security, мои мысли здесь не являются официальными, и я приглашаю вас принять мои слова с недоверием.

Этот вопрос "почему нет проекта с открытым исходным кодом Xразоблачили Y вещь еще? "в основном сводится к нескольким вещам:

• Практика программирования достаточно распространена, так что добавление хука для отклонения от него может быть более запутанным, чем полезным для пользователей
• Любой добавленный хук являетсякрючок сохраняется вечно.Цикл устаревания очень длинный
• У пользователей уже есть простая альтернатива
• Использование хука будет несовместимо с аналогичными местами в коде
• Отклонение от практики программирования небезопасно /плохая практика / и т. д., поэтому сопровождающие хотят убедиться, что переопределение просто, но не обязательно просто переключение

В сочетании с тем фактом, что MessageDigestPasswordEncoder является @Deprecated простоозначает, что случай для добавления просто должен быть сильным.

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

Вместо этого @ jb-nizet указал, что довольно просто выставить свой собственный кодер (и использовать API кодировщика паролей для переноса ваших паролей).Или, если это не сработает, тогда зарегистрируйте заявку с командой, и мы посмотрим!