Как управлять паролями в веб-приложениях?

Question

Каков современный метод хранения паролей пользователей в веб-приложениях? Я работаю с Java 6 + MySQL. Некоторые из вопросов, которые я имею в виду: лучше ли кодировать в приложении или с помощью СУБД (это вообще актуально)? Какой алгоритм считается надежным? Что хранить в базе данных? Действительно новичок в этом деле, поэтому, возможно, пропустил некоторые важные детали, в этом случае, пожалуйста, не стесняйтесь, дайте мне знать.

Спасибо.

Answer 1

bcrypt - надежный алгоритм хеширования пароля.Он был создан профессионалами в области безопасности с заботой о безопасности.

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

Java-реализация bcrypt доступна по адресу jBCrypt .

Answer 2

Вы должны хранить надежно хэшированные и соленые версии паролей к базе данных.Таким образом, если ваш сайт взломан, так как пользователи используют один и тот же пропуск почти везде, их другие учетные записи не скомпрометированы.

Для этого необходимо выполнить следующее:

1. Использоватьалгоритм безопасного хеширования, который еще не нарушен (предпочтительно SHA-512, Sha1 и MD5 не работают )
2. Объединение Имя пользователя + Пароль + Соль (соль должна быть относительнодлинная постоянная строка, которая одинакова во времени в вашем приложении и предотвращает атаки Rainbow при определенных усилиях)
3. SHA-512 результат объединения и сохраняет его в базе данных.
4. каждый раз впользователь пытается войти в систему, хэширует свои учетные данные, используя тот же метод, и проверяет данные в базе данных, если они совпадают, их правильность.

Не важно, где вы хэшируете пароли (приложение илиБД), но БД имеют ограниченную функциональность безопасного хеширования, поэтому лучшим выбором будет приложение.

Answer 3

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

1- Большинство атак происходит при передаче учетных данных по проводам. (Человек посередине). Поэтому вам необходимо убедиться, что передача имени пользователя и пароля должна быть безопасной. (ssl или HTTP Digest). Если безопасность очень важна, вам следует выяснить, нужно ли вообще передавать имя пользователя \ пароль. (используя некоторую аутентификацию на основе токенов, такую ​​как Oauth вместо имени пользователя и пароля)

2 - В случае, если вы решите передать имя пользователя и пароль, вам необходимо сократить время жизни строки пароля в области приложения. Конечно, лучший способ - реализовать фильтр аутентификации на основе такого механизма, как LDAP. Большинство хранилищ LDAP позволит вам хранить зашифрованный пароль и позволит вам выполнять аутентификацию с помощью привязки (так что ваше приложение никогда не будет беспокоиться об аутентификации и хранении)

3- В случае, если вы действительно перенесете свой пароль на уровень приложения, вам, конечно, все равно нужно сократить время жизни вашего открытого текста и шифровать его, используя некоторый безопасный алгоритм хеширования. Но такой подход и хранение пароля в вашей базе данных (даже в зашифрованном виде) не так уж безопасны. (особенно если вы храните пароль, кто-то может обойти ваш уровень безопасности)

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

1- Если вам нужно отправить имя пользователя / пароль?

2- Можете ли вы убедиться, что пароль не может быть перехвачен по сети?

3- Разве вы не можете делегировать свою аутентификацию переднему фильтру вместо того, чтобы переходить на уровень вашего приложения?