Когда браузер отправляет предоставленные вами данные, он отправляет их в формате, который наиболее вероятно соответствует требованиям RFC для протокола, по которому он взаимодействует с сервером.
В случае HTTP-соединения имя пользователя и пароль отправляются в открытом виде (то есть в виде простого текста) на ваш веб-сервер.
В случае соединения HTTPS все, отправляемое клиентом на сервер с поддержкой HTTPS (после рукопожатия), шифруется — как только оно поступает на сервер, оно расшифровывается. Какой бы программный стек вы ни использовали на стороне сервера, он должен обрабатывать это прозрачно для вас, поэтому вы снова будете иметь дело с данными в открытом виде.
В любом случае вы должны всегда хешировать пароли, которые вы храните. Причина не в том, чтобы сохранить пароль, когда он передается по сети (т. е. между клиентом и сервером). Причина в том, чтобы сохранить пароль в безопасности в вашей базе данных — самый безопасный способ сохранить секрет — не хранить его.
Хеширование на стороне клиента вообще небезопасно, так как оно раскрывает не только выбранный вами метод хеширования, но и ваш механизм соления (и, для скомпрометированного клиента, фактическое значение соли).
Что касается наилучшего способа хеширования... выберите прилично безопасный алгоритм хеширования (один из семейства SHA должен хорошо справляться) и динамическую соль (тот, который отличается для каждого пользователя, например, дату присоединения и каждую другую букву их адрес электронной почты). Если вы хотите сделать его более безопасным, хешировать хэш несколько (тысяч) раз. Таким образом, даже если у вас украдут всю вашу базу данных, потребуется значительный объем работы, чтобы раскрыть даже небольшой процент ваших паролей, что избавит людей, которые повторно используют пароли, от серьезных головных болей.
person
Sean Vieira
schedule
08.06.2011
