Действительно ли возможно хешировать пароль и аутентифицировать клиентского пользователя?
это удалит компонент времени из даты Вас:
select dateadd(d, datediff(d, 0, current_timestamp), 0)
6 ответов
Это возможно. На самом деле это то, что делает аутентификация Kerberos, только с небольшими добавками. Чтобы гарантировать безопасность вашего механизма аутентификации, вам потребуется следующее:
- Общий алгоритм хеширования как на клиенте, так и на сервере.
- Одноразовое значение соли, генерируемое на сервере и передаваемое клиенту.
- Исходный пароль хранится в базе данных.
Чтобы безопасно аутентифицировать пользователя с помощью хэш-кода, чтобы вы не отправляли фактический пароль по сети, сначала сгенерируйте случайное одноразовое значение соли на сервере. Отправьте это значение соли клиенту и сгенерируйте хэш-код из версии пароля, введенного пользователем. Отправьте полученный хэш-код на сервер и сравните его с хэш-кодом, сгенерированным из соленой версии сохраненного пароля. Если сравнение не удалось, отказаться от соли, восстановить новое значение соли и повторить процесс.
Причина одноразовой соли состоит в том, чтобы не дать никому, кто слушает разговор, перехватить хэш-код пароля пользователя, который при использовании хеш-кода сравнение кода, так же хорошо, как наличие самого пароля.
Обратите внимание, что вам нужно сохранить исходный пароль, вы не можете хешировать его один раз на сервере и сохранить хеш в базе данных. Если вам нужно убедиться, что пароли, хранящиеся в вашей базе данных, также защищены, вам нужно будет зашифровать их перед сохранением. Я считаю, что провайдеры членства в ASP.NET позволяют хранить пароли в зашифрованном виде, однако, если вы действительно хотите иметь безопасный механизм аутентификации, который хакеру трудно взломать, то я бы порекомендовал полностью управлять хранением и поиском паролей самостоятельно.
Наконец, я должен отметить, что такой сложный механизм передачи пароля должен быть в значительной степени ненужным, если вы используете SSL для шифрования вашего соединения во время аутентификации.
Ссылки (для тех, кто никогда не слышал о Kerberos или SRP):
http://en.wikipedia.org/wiki/Kerberos_ (протокол) 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 нет ни встроенного клиентского компонента, ни компонента на стороне сервера для генерации / проверки этого, поэтому вам нужно делать все вручную. Также требуется, чтобы ваше хранилище сохраняло определенный хэш-формат, см. Хранение пароля в таблицах и дайджест-аутентификация
. Преимущество состоит в том, что вы следуете хорошо проанализированному и понятному протоколу аутентификации. Не катите свой собственный.