Протокол для использования хэширования паролей с солью

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

Когда пользователь регистрируется при входе в систему, имя пользователя и пароль вводятся на стороне клиента. Я хочу знать, какая информация отправлена. Веб-клиент отправляет пароль в виде обычного текста или использует javascript для хеширования пароля БЕЗ соли и отправляет результат hased? Или клиент получает соль в виде обычного текста с сервера, а затем клиент отправил hased password + salt?

Каков наилучший способ хеширования и хэш с солью? MD5 нормально как хэш? Как hash (password_plain_text + salt) против хеша (hash (password_plain_text) + соль), где + - конкатенация строк?

3 ответа

Когда браузер отправляет данные, которые вы предоставили, он отправляет их в формате, который, скорее всего, соответствует требованиям RFC (-ов) для протокола, который он обменивается с сервером.

В случае HTTP-соединения имя пользователя и пароль отправляются в ясном (то есть в обычном тексте) на ваш веб-сервер.

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

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

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

Что касается наилучшего способа хеширования... выберите достойный безопасный алгоритм хэширования (один из членов SHA-семейства должен хорошо сделать трюк) и динамическую соль (которая отличается для каждого пользователя, например дата присоединения и каждая другая буква их адреса электронной почты). Если вы хотите сделать его более безопасным, хэш хэш несколько (тысяч) раз. Таким образом, даже если вам удастся украсть всю вашу базу данных, потребуется значительная работа, чтобы выявить даже небольшой процент ваших паролей, тем самым избавляя людей от повторного использования паролей в виде серьезных головных болей.


JavaScript отправляет все, что вы скажете, чтобы отправить. Если вы явно не храните пароли через JavaScript, они отправляются в открытом тексте на сервер, который их хеширует.

Я не думаю, что это была бы отличная идея для хэша на стороне клиента, хотя, поскольку это будет показывать вашу соль всем, кто смотрит на ваш JavaScript. Кроме того, пользователи без включенного JavaScript не смогут входить в систему.

Хеш на сервере.

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

Но если вас действительно беспокоит безопасность, хэш с SHA256. Google " md5 collisions", чтобы узнать, почему MD5 не является лучшей функцией хэширования (она является одной из самых быстрых).


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

licensed under cc by-sa 3.0 with attribution.