Хэширование паролей перед отправкой на сервер

Question

При отправке паролей через передачу сокета в кодировке UTF-8 считается ли это безопасным, если я хэширую пароль с использованием MD5 или SHA-1 до отправки данных?Имейте в виду, что я планирую сравнить хешированный пароль в базе данных SQL.Я обеспокоен тем, что кто-то может прослушать хешированный пароль в UTF-8, затем расшифровать кодировку UTF-8 и получить мой хешированный пароль, который потенциально может быть использован для сопоставления пароля в моей базе данных.

Answer 1

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

Если протокол аутентификации состоит в том, чтобы просто представить фрагмент секретных данных (если хотите, назовите его паролем), то обмен должен происходить в транспортной среде, которая обеспечивает конфиденциальность (чтобы секретные данные не могли быть прослушаны), и на сервере. аутентификация (чтобы злоумышленник не мог имитировать сервер и убедить клиента отправить ему секретные данные). Это то, что вы получаете из классического туннеля SSL / TLS (https:// URL, в веб-контексте).

Если вы не можете установить туннель SSL / TLS с аутентификацией сервера (т. Е. У сервера есть сертификат, который клиент может проверить), то вы можете прибегнуть к протоколу аутентификации с проблемой: сервер отправляет случайную последовательность байты (вызов), и клиент отвечает хеш-значением, вычисленным по соединению пароля и запроса. Не пытайтесь повторить это дома! Это очень сложно сделать правильно, особенно когда злоумышленник может перехватить связь (активные атаки).

Более общий ответ - обмен ключами с аутентификацией по паролю протоколы. PAKE объединяет протокол соглашения о криптографическом ключе (например, Диффи-Хеллмана) и взаимную аутентификацию по паролю между клиентом и сервером таким образом, что побеждает как пассивных, так и активных злоумышленников, даже при относительно слабых паролях (злоумышленник не может получить достаточно данных для «попытки») пароли без взаимодействия с клиентом или сервером для каждой догадки). К сожалению, несколько алгоритмов PAKE были стандартизированы за пределами математического описания, и область является открытым минным полем.

Answer 2

Что ж, если кто-то может прослушать хеш - он может подделать запрос на авторизацию и отправить хеш, который он уже знает.

Создание защищенной системы не так просто, вам необходимо выполнить авторизацию с использованием асимметричной криптографии с правильно подписанными ключами, чтобы сделать ее защищенной.

По крайней мере, добавить ~ 100-байтовую случайную соль и использовать SHA1таким образом, было бы гораздо труднее перебрать силы.

Answer 3

Они могут взломать ваши пароли, если знают алгоритм хеширования. Простое (и не совсем безопасное) решение состоит в том, чтобы вместо этого использовать запрос / ответ, сервер выдает случайную строку («nonce») для хеширования вместе с хэшем пароля. Это делает ваше приложение неуязвимым для тех атак повторного воспроизведения, которые вы описываете.

Для получения дополнительной информации см. HTTP дайджест-аутентификация доступа

.

Answer 4

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

Если вы беспокоитесь о перехватчиках паролей, вы можете перейти на следующий уровень - использовать шифрование PRIVATE / PUBLIC key. Сервер должен отправить запрос клиенту (открытый ключ для шифрования), клиент шифрует его, и только сервер знает, как его расшифровать. Для того же количества бит, он предлагает больше защиты - т.е. Чтобы грубо заставить его взломать, нужно больше мускулов.

Проверьте это из.

Answer 5

Как проверить пароль на стороне базы данных?

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

Это так же, как если бы вы хранили пароль в базе данных в виде простого текста.

Если вы боитесь нюхать, используйте протокол «запрос-ответ» для аутентификации, но в этом случае секрет будет храниться в базе данных (и будет известен любому, кто имеет доступ к базе данных).

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