протокол для использования хеширования пароля с солью - PullRequest
3 голосов
/ 08 июня 2011

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

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

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

Ответы [ 3 ]

6 голосов
/ 08 июня 2011

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

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

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

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

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

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

3 голосов
/ 08 июня 2011

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

3 голосов
/ 08 июня 2011

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

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

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

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

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

...