Имеет смысл безопасности хешировать пароль на клиентском конце
Это ( отсюда ) работало на меня:
git checkout aq
git pull origin master
git push
7 ответов
Нет.
Когда клиент отправляет что-то , будь то P или H (P) или H (H (P)) любой, кто перехватывает это, может просто повторно отправить то же самое , таким образом делая любую подобную функцию эквивалентной использованию пароля напрямую.
Вот почему вам следует используйте одноразовый номер ; Сервер может выдать случайный мусор k , а клиент вычислит H (P, k) и отправит его на сервер. HMAC - популярная реализация этого метода.
Если сервер никогда никогда не принимает один и тот же одноразовый номер дважды, это защищает от повторной атаки.
Хэш идентичен паролю из точки обзора безопасности в описанном вами сценарии: если я перехватываю хеш, мне не нужно знать пароль, я могу просто отправить серверу хэш, который я перехватил.
Протоколы аутентификации идут на определенную длину, чтобы избежать этой проблемы; безопасность - это сложная задача, и вам лучше выбрать и реализовать хорошо понятный протокол, а не использовать собственный.
Если ваш трафик проходит через SSL, вы защищены от перехвата, а хеширование не даст дополнительных преимуществ.
Нет, хеширование на клиенте не защищает пароль «полностью». Когда кто-то решает хешировать пароль на клиенте, то дайджест, отправленный на сервер, по существу становится паролем. Это не проблема сама по себе, если используется SSL.
Однако эта схема в конечном итоге создает больше проблем, чем решает. Если бы сервер сравнивал хэш, представленный клиентом, с хешем, хранящимся в базе данных без выполнения каких-либо дальнейших криптографических операций (особенно хеширования входных данных), то пароль сохраняется в виде открытого текста для всех практических целей. Любой человек, имеющий доступ к сохраненному хешу, может повторно отправить его на сервер и получить доступ к учетным записям.
Проще говоря,
Отправка хешированного пароля не улучшит безопасность вашего сайта, как указывали другие (поскольку вы принимаете хешированный пароль, все, что нужно знать злоумышленнику, - это хешированная версия). Это также не совсем безопасно, так как злоумышленник предположительно может загрузить вашу страницу входа и проверить развернутый Javascript или Java.
Что он делает, так это препятствует тому, чтобы кто-то, наблюдающий за пакетами, мог вытащить пароль, а это умеренно полезно. Многие люди используют один и тот же пароль на нескольких сайтах (я делаю это для всех, кроме сайтов с более высоким уровнем безопасности), и поэтому, если вы можете получить от них один пароль, вы можете войти в другие учетные записи на других сайтах.
Это также предотвращает настоящую пароль от хранения, даже временно, на вашем сайте, и это может обеспечить небольшую дополнительную безопасность, если ваш сайт будет взломан.
Итак, Хотя я считаю хеширование на стороне пользователя потенциально хорошей вещью, не стоит тратить много времени на дополнительные хлопоты.
И, как вам говорили другие, не изменяйте собственную безопасность. Слишком много вещей может пойти не так. Вы не заметите их почти так же быстро, как это заметит опытный плохой парень.
Просто убедитесь, что вы отправляете свой пароль через защищенный канал (SSL). Если клиент может читать частную память приложения, то, скорее всего, у него есть более серьезные проблемы, например, кейлоггер.
Было бы намного лучше, если бы вы использовали протокол безопасного удаленного пароля (SRP ). Он был разработан для этого.
Хеширование на клиентская сторона открывает еще одну огромную дыру: вы можете раскрыть алгоритм хеширования. Вы не говорите, веб-интерфейс (клиент = JavaScript) или толстый клиент, но вы даете им больше информации. Учитывая, что канал безопасен, вам не нужно беспокоиться о том, что пароль в виде открытого текста будет перехвачен.
Кроме того, если ваш алгоритм хеширования требует наличия соли, вы ее обнажите, что означает, что если они когда-либо получат доступ к базы данных, они смогут расшифровать любой пароль.