Я что-то упускаю из-за полезности хэшей

Question

Итак, хэши полезны, потому что они изменяют комбинации пароль / имя входа / соль-значение на код, который нельзя отменить. Клиент отправляет этот хэш на сервер. Сервер сравнивает хеш со списком сохраненных хешей, чтобы увидеть, может ли пользователь клиента получить доступ. Но как мне запретить злоумышленнику перехватить хешированный пароль и написать свой собственный клиент, который отправляет этот хеш на сервер?

Answer 1

То есть Человек в середине Атаки и ничего с хэшированием, для смягчения таких атак мы используем Secure Sockets Layer и аналогичные технологии.

Answer 2

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

Как вы указали, они не останавливают перехват запросов ( Человек посередине атакует ), чтобы прекратить использование безопасных соединений с шифрованием и подписью пакетов. HTTPS & SSL являются наиболее распространенными способами сделать это.

Answer 3

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

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

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

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

Answer 4

Никакие хэши не используются таким образом. Клиент сначала отправляет пароль (я предлагаю использовать SSL), затем сервер вычисляет хеш на основе этого пароля с солью и сравнивает его со своими данными в хранилище паролей. Таким образом, плохие пользователи не смогут получить пароли.

Answer 5

Во многих системах хэшированное значение не является статическим, но использует nonce каждый раз, когда запрашивается действие, требующее аутентификации. Сервер отправляет клиенту уникальное значение, которое объединяется с секретом и хэшируется. Это может предотвратить повторные атаки типа «человек посередине».

Answer 6

Зависит от способа перехвата.

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

Чтобы остановить перехват сетевых соединений, убедитесь, что вы используете SSL (т. Е. HTTPS, а не HTTP). HTTP, вероятно, наиболее уязвим в домашней или офисной сети, в частности в слабо защищенной беспроводной сети. HTTPS даст вам некоторую защиту от скомпрометированной сети. Это также включает анализаторы пакетов в локальных сетях.

Последний вариант - компьютеры, которыми пользуются несколько человек. Интернет-кафе являются одним из примеров. Работа ПК может быть другой. Вы можете установить низкий тайм-аут, чтобы минимизировать риск этого.

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

Answer 7

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