Имеет ли смысл безопасности хэш-пароль на стороне клиента

Ответ 1

Нет.

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

Вот почему вы должны использовать nonce; Сервер может выдавать некоторый случайный мусор k, и клиент будет вычислять H(P,k) и отправлять его на сервер. HMAC является популярной реализацией этого метода.

Если сервер никогда не принимает одно и то же второе очко, это защищено от атаки повтора.

Ответ 2

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

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

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

Ответ 3

Отправка хешированного пароля не улучшит безопасность вашего сайта, как указывали другие (поскольку вы принимаете хешированный пароль, все, что должен знать плохой парень, это хешированная версия). Это также не очень безопасно, так как плохой парень может предположительно загрузить вашу страницу входа в систему и изучить развернутый Javascript или Java.

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

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

Итак, хотя я считаю, что хэширование на стороне пользователя потенциально может быть хорошим, не стоит особо беспокоиться.

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

Ответ 4

Да, вы должны.

IEEE имел нарушение данных, в котором 100K писем и паролей были выставлены из веб-журнала.

http://ieeelog.com/

Очевидно, что IEEE не должен был раскрывать свой блог! Но если бы они хэшировали пароли на стороне клиента, это было бы не так уж плохо.

Как говорится в первом ответе, вы должны использовать nonce. Если вы используете достаточно длинный nonce (например, 128 бит), вам не нужно беспокоиться о повторном использовании, так как сервер никогда не будет запрашивать одно и то же nonce дважды (предполагая правильно высеянную CRNG и т.д.).

Ответ 5

Нет, хеширование на клиенте не защищает пароль "полностью". Когда вы выбираете хеш-пароль на клиенте, то дайджест, представленный на сервере, по сути становится паролем. Это не проблема сама по себе, если SSL развернут.

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

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

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

Ответ 6

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

Ответ 7

Я думаю, что это имеет смысл в одном случае; вы не хотите даже знать пароль открытого текста клиента. Если вы hash на стороне клиента, то соль и итеративно хеш, что хэш так же, как вы бы открытым текстом pw. Кроме этого, это своего рода глупость.

Ответ 8

Вам было бы намного лучше, если бы вы использовали протокол безопасного удаленного пароля (SRP). Он был разработан для этого.

Ответ 9

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

Ответ 10

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

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