Каков наилучший способ хэширования пароля пользователя в браузере клиента, прежде чем отправлять его на веб-сервер, так что выходит только хеш, а не пароль с открытым текстом?Хеширование паролей в браузере клиента
EDIT: если предположить HTTP используется (не HTTPS)
Использования Javascript для вычисления хэша. См. this для примера о том, как рассчитать хэши SHA-1 в JS.
Опасайтесь, что если вы зависнете от Javascript, ваша система будет терпеть неудачу, как только кто-то отключит JS. Вы должны использовать HTTPS, если это вас беспокоит, у которого есть свои неудачи (например, сертификаты стоят денег, если вы хотите, чтобы они были немедленно приняты браузерами.)
Не все люди имеют JavaScript в своих браузерах и даже идея отправки хэшей на текстовом канале, я думаю, недостаточно безопасен.
Я бы рекомендовал вам установить защищенное соединение SSL.
Попробуйте использовать это jQuery encryption plugin. Из любопытства, что не так с использованием SSL/HTTPS и шифрования на стороне сервера?
Я предполагаю, что работаю над простым HTTP – Andy
Этот сайт имеет достаточно всеобъемлющий материал хеширования/крипто: JavaScript Encryption Library
JavaScript шифрование на стороне, как библиотеки JQuery шифрования останавливается прослушки. Однако MITM (Man-in-the-Middle) все еще может произойти. SSL/TLS - это идеальный выбор, который рекомендуется делать, если вы не используете общий хостинг (нет выделенных IP-адресов), или ваш сайт получает столько трафика, что вы не можете просто шифровать все соединения (JS, CSS, HTML, .. .).
Зачем вам это надоело? Фактически, хэш пароля стал паролем, а человек-в-середине, который перехватывает хэш, может использовать его для аутентификации и выполнения любых действий в качестве пользователя. С другой стороны, если вы не верите в человека в середине, почему бы просто не отправить сам пароль?
Challenge-Response защищает от подслушивания - где вы не можете изменять какие-либо данные, но просто слушайте его. Поскольку жетоны одноразовые, подслушивающие устройства всегда опаздывают и не используют токен. – Tower
Да, это правда, я полагаю, это остановит атакующего только подслушивающего устройства от обнаружения пароля. Но в этом случае я просто просто использую HTTP-дайджест-аутентификацию, а не сворачиваю сам. – erickson
Почему мы имеем хэш-пароли? Таким образом, если хеши будут получены, их будет сложно использовать.
Что происходит в этой модели, если хэши в системе открыты? Злоумышленник просто отправляет их на сервер и аутентифицируется как пользователь.
Именно поэтому хеширование пароля всегда происходит на сервере, а не на клиенте!
Надеюсь, вы планируете либо отправлять хэш по защищенному каналу, либо это часть механизма вызова/ответа. В противном случае это не более безопасно, чем отправка самого пароля в виде простого текста ... –
@Roger Lipscombe, этот метод может фактически немного улучшить для пользователя. Даже если нет безопасного канала (только SSL будет работать, альтернатива JS не будет пуленепробиваемой), то он, по крайней мере, сделает хэш уникальным для сайта. Чтобы сделать хэш уникальным, конечно, * его нужно солить *. – Inshallah
Предоставлено, что это сделает хэш уникальным для сайта - полезно, если пользователь использует один и тот же пароль на нескольких сайтах; не препятствует повторному воспроизведению с тем же сайтом. И, конечно, если хэш будет солен, то либо соль должна идти от клиента к серверу - не более безопасна, чем раньше; или другим способом, и в этом случае это вызов или ответ. –