Spring Security/Ключевые сервисы Spring Security: различия между версиями
Содержимое удалено Содержимое добавлено
TonyR (обсуждение | вклад) |
TonyR (обсуждение | вклад) |
||
Строка 116:
== Добавление «Соли» к Хешу ==
Существует одна потенциальная проблема с использованием хеш-значения для паролей, можно сравнительно легко обойти свойство однонаправленности хеша, если в качестве входных данных используются частоупотребляемые слова. Например, если поищете в Google хэш-значение <tt>5f4dcc3b5aa765d61d8327deb882cf99</tt> помощью Google, то быстро найдете оригинальные слово "password". Аналогичным образом, злоумышленник может построить словарь хэшей из стандартного списка слов и использовать его для поиска оригинального пароля. Один из способов избежать этого является наличие соответствующей строгой политики создания паролей, чтобы попытаться предотвратить использование часто встречающихся слов. Также можно использовать "соль" при вычислении хэшей. Это дополнительная строка каких то данных для каждого пользователя, которые комбинируются с паролем до вычисления хэша. В идеале данные должны быть случайной последовательностью, но на практике лучше любое значение для соли чем его отсутствие. В Spring Security имеется интерфейс <code>SaltSource</code>, который может быть использован аутентификационным провайдером для генерирования значения соли для конкретного пользователя. Использование соли означает, что злоумышленник будет вынужден построить отдельный словарь хэшей для каждого значения соли, что делает атаку более затруднителной(но не невозможной).
== Хеширование и аутентификация ==
Когда аутентификационному провайдеру (такому как <code>DaoAuthenticationProvider</code>) нужно сверить пароль, присланный в аутентификационном запросе со значением, которое известно для данного пользователя и пароль хранится в закодированном виде, то тогда присланное значение должно быть закодировано с помощью точно такого же алгоритма. Совместимость алгоритмов это полностью ваша зона ответственности. Spring Security не может контролировать хранимые значения. Если вы добавили хеширование паролей в конфигурацию аутентификации Spring Security, а в базе данных пароли хранятся в виде обычного не шифрованного текста, то в это случае аутентификация не произойдет ни при каких обстоятельствах. Например, даже если вы знаете что в базе данных используется MD5 кодирование и ваше приложение сконфигурировано так, чтобы использовать <code>Md5PasswordEncoder</code> из состава Spring Security, то все равно есть возможность получить ошибку. В базе данных кодированные пароли могут храниться в виде <tt>Base64</tt> , а кодировщик Spring Security например будет использовать строки с шестнадцатеричными значениями (по умолчанию) [5]. Или в базе данных сведения будут хнариться в верхнем регистре, а результат работы кодировщика будет в нижнем регистре. Обязательно напишите тест, который будет сверять результат работы настроенного кодировщика (на основе известного пароля и «соли») с данными хранящимися в базе данных, до того как двигаться дальше и применять механизм аутентификации в вашем приложении. Для получения дополнительной информации, как по умолчанию происходит слияния соли и пароля, см. Javadoc для <code>BasePasswordEncoder</code>. Если вы захотите создавать закодированные пароли непосредственно в Java коде и уже их сохранять в базе данных, то вы можете использовать метод <code>encodePassword</code> класса <code>PasswordEncoder</code>.
| |||