Можно ли хешировать пароль и аутентифицировать пользователя на стороне клиента?

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

1. Общий алгоритм хеширования как на клиенте, так и на сервере.
2. Одноразовое значение соли, генерируемое на сервере и передаваемое клиенту.
3. Исходный пароль хранится в базе данных.

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

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

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

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

Ссылки (для тех, кто никогда не слышал о Kerberos или SRP):

http://en.wikipedia.org/wiki/Kerberos_(protocol) http://en.wikipedia.org/wiki/Secure_remote_password_protocol

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

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

Добавлено для ясности:

Само по себе хеширование на стороне клиента небезопасно. Скажем, у меня есть форма со следующими данными

<form action="signin.whatever" method="post">
<input type="text" id="txtUser">
<input type="text" id="txtPass">
<input type="hidden" id="hiddenHash">
<input type="submit" onclick="hashAndSubmit()">
</form>

где hashAndSubmit () хеширует пароль и помещает его в hiddenHash, а поле пароля вычеркивает. Если я понюхаю ваше сообщение и увижу следующие поля:

txtUser:joeuser
txtPass:
hiddenHash:xxx345yz   // hash result

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

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

Доверяю ли я себе больше, чем годы и годы публичного тестирования шифрования SSL?

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

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

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

Вы можете отправить в качестве полей сообщения хэш имени пользователя / области / пароля, следуя протоколу HTTP Digest. AFAIK нет ни встроенного клиентского компонента, ни компонента на стороне сервера для генерации / проверки этого, поэтому вам нужно делать все вручную. Также требуется, чтобы ваше хранилище сохраняло определенный хэш-формат, см. Хранение пароля в таблицах и Дайджест-аутентификация

Преимущество состоит в том, что вы следуете хорошо проанализированному и понятному протоколу аутентификации. Не скручивайте свои собственные.