Имеет ли смысл использовать хэш-пароль на стороне клиента?
Если бы вы хэшировали пароль пользователя до его отправки через строку и оставляли его в виде простого текста в памяти, улучшило бы это безопасность приложения?
Я бы предположил, что это уменьшает небольшую часть уязвимостей, защищая данные, хранящиеся в памяти клиентов. Но на самом деле, если мы беспокоимся о том, что кто-то читает память клиента, возможно, есть более серьезные проблемы, которые мы не можем решить.
Есть что-то, что не подходит для хэширования на стороне клиента.
Является ли хеширование пароля на стороне клиента обычной практикой? Есть ли другие преимущества или недостатки в этом?
РЕДАКТИРОВАТЬ: Учитывая, что канал связи является безопасным (SSL). При каких условиях было бы приемлемо и целесообразно использовать такой подход. Я спрашиваю об этом, потому что "специалист по безопасности" предложил мне использовать такую схему во время некоторых функций приложения.
11 ответов
Нет.
Когда клиент что-то отправляет, будь то P или же H(P) или же H(H(P)) любой, кто перехватывает это, может просто отправить ту же самую вещь, таким образом делая любую функцию, подобную этой, эквивалентной прямому использованию пароля.
Вот почему вы должны использовать одноразовый номер; Сервер может выдать какой-то случайный мусор k и клиент рассчитает H(P,k) и отправить его на сервер. HMAC является популярной реализацией этого метода.
При условии, что сервер никогда не принимает один и тот же одноразовый номер дважды, это защищает от атаки воспроизведения.
Отправка хешированного пароля не улучшит безопасность вашего сайта, как отмечали другие (поскольку вы принимаете хешированный пароль, все, что нужно знать злоумышленнику, это хешированная версия). Это также не совсем безопасно, поскольку злоумышленник может предположительно загрузить вашу страницу входа в систему и изучить развернутый Javascript или Java.
Что он делает, так это предотвращает возможность извлечения пароля кем-то, наблюдающим за пакетами, и это в меру полезно. Многие люди используют один и тот же пароль на нескольких сайтах (я делаю это для всех, кроме сайтов с более высоким уровнем безопасности), и поэтому, если вы можете получить один пароль от них, вы можете войти в другие учетные записи на других сайтах.
Это также предотвращает сохранение реального пароля, даже временно, на вашем сайте, и это может обеспечить дополнительную безопасность, если ваш сайт будет взломан.
Так что, хотя я считаю, что хеширование на стороне пользователя потенциально полезно, не стоит слишком много хлопот.
И, как говорили другие, не сверните свою собственную безопасность. Слишком много вещей, которые могут пойти не так. Вы не заметите их так быстро, как это сделает практикующий плохой парень.
Да, ты должен.
В IEEE произошла утечка данных, из-за которой 100 тысяч электронных писем и паролей были раскрыты в блоге.
Очевидно, IEEE не должен был выставлять свой блог! Но если бы они хэшировали пароли на стороне клиента, это было бы не так плохо.
Как говорится в первом ответе, вы должны использовать одноразовый номер. Если вы используете достаточно длинный одноразовый номер (например, 128 бит), вам не нужно беспокоиться о повторном использовании, поскольку сервер никогда не будет запрашивать один и тот же одноразовый номер дважды (при условии правильного заполнения CRNG и т. Д.).
Хэш идентичен паролю от POV безопасности в сценарии, который вы описываете: если я перехватываю хеш, мне не нужно знать пароль, я могу просто отправить серверу хеш, который я перехватил.
Протоколы аутентификации идут до некоторой длины, чтобы избежать этой проблемы; Безопасность сложна, и вам лучше выбрать и внедрить понятный протокол, а не использовать собственный.
Если ваш трафик идет по SSL, вы защищены от перехвата, а хеширование дает вам немного дополнительных преимуществ.
Нет, хеширование на клиенте не защищает пароль "полностью". Когда выбирается хеширование пароля на клиенте, тогда дайджест, отправленный на сервер, по сути становится паролем. Само по себе это не проблема, если развернут SSL.
Однако эта схема создает больше проблем, чем решает. Если сервер сравнивает хеш, предоставленный клиентом, с хешем, сохраненным в базе данных, без выполнения каких-либо дополнительных криптографических операций (особенно хеширования входных данных), тогда пароль хранится в виде открытого текста для всех практических целей. Любой человек, имеющий доступ к сохраненному хешу, может повторно отправить его на сервер и получить доступ к учетным записям.
Проще говоря, если переданный хэш (который совпадает с переданным хэшем) должен был утечь через любую другую уязвимость в приложении (например, посредством SQL-инъекции), то у приложения есть уязвимость, в которой он защищает пароли неадекватно.
Если базовая уязвимость должна быть исправлена, то необходимо рассматривать переданный хэш как пароль в виде открытого текста, который затем должен быть хеширован (предпочтительно с солью) перед сравнением с сохраненным хешем.
Я думаю, что это имеет смысл в одном обстоятельстве; Вы не хотите даже знать пароль клиента в незашифрованном виде. Если вы хешируете на стороне клиента, то солите и итеративно хешируете хеш-код так же, как и обычный текст pw. Кроме этого, это немного глупо.
Просто убедитесь, что вы отправляете свой пароль через безопасный канал (SSL). Если клиент может прочитать частную память приложения, то, скорее всего, у него будут большие проблемы, например, кейлоггер.
Было бы гораздо лучше, если бы вы использовали протокол безопасного удаленного пароля (SRP). Это было разработано для этого.
Да, имеет смысл хешировать пароль на стороне клиента, даже если вы используете SSL, но все же вы должны также снова хешировать его на стороне сервера.
Это имеет смысл, особенно в случае мобильного приложения. Если вы хешируете на стороне клиента даже с «постоянной солью» / строкой домена, это будет намного лучше, чем отправка пароля в виде открытого текста, даже если вы используете SSL. Если вы отправляете на сервер пароли в виде обычного текста, то в случае, если кто-то взломает ваш сервер, он получит пароль в виде обычного текста. Таким образом, добавление дополнительного предварительного хеширования на стороне клиента защищает пользователей и их пароли, которые они, вероятно, используют и в других местах.
Вы, вероятно, найдете много сообщений, в которых говорится, что хеширование на стороне клиента не требуется, но они обычно связаны с веб-приложениями и не рассматривают случай мобильного приложения. В случае веб-приложения, если кто-то взломает сервер, он может заменить веб-сайт и в любом случае удалить хеширование на стороне клиента, так что в этом случае нет такого большого преимущества. Но для мобильных приложений злоумышленник не может заменить код мобильного приложения, поэтому хеширование на стороне клиента в этом случае имеет большой смысл.
Вы можете проверить эту ссылку на возможное решение с хешированием как на стороне клиента, так и на стороне сервера: https://medium.com/@harwoeck/password-and-credential-management-in-2018-56f43669d588
Так что да, хеширование как на стороне клиента, так и на стороне сервера.
Я могу предложить вам другой подход. Если у вас нет SSL, вы можете хешировать пароль на стороне клиента, и он снова хэшируется на стороне сервера, используя другой метод хеширования, и сохраняет их в базе данных, а когда логин пользователя с паролем делает тот же процесс и совпадает с двойным хэшированием. пароль с сохраненными хешами
Хеширование на стороне клиента открывает еще одну огромную дыру: вы можете раскрыть алгоритм хеширования. Вы не говорите, является ли это веб-интерфейсом (клиент =JavaScript) или толстым клиентом, но вы даете им больше информации. Поскольку канал защищен, вам не нужно беспокоиться о том, что пароль будет перехвачен.
Кроме того, если ваш алгоритм хеширования требует соли, вы бы выставили свою соль, что означает, что, если они когда-нибудь получат доступ к базе данных, они смогут расшифровать каждый пароль.