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

Question

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

Answer 1

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

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

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

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

Answer 2

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

Для получения дополнительной информации см в HTTP digest access authentication

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Проверьте this вне.