Где я солю и хеширую свои пароли?На клиенте или на хосте? - PullRequest
3 голосов
/ 02 июля 2011

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

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

Ответы [ 3 ]

8 голосов
/ 02 июля 2011

Отправка или парольной фразы или ее хеша позволяет атакующему записать хеш и использовать его при повторной атаке.

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

Это позволяет вам проверять соответствие ключей без каждой отправки самого ключа по небезопасному каналу.

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

3 голосов
/ 02 июля 2011

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

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

Вы хотите хешировать пароль на стороне клиента, только если вы собираетесь хранить этот пароль локально, например, на мобильном устройстве. Как правило, вы хотите выполнить хэширование на уровне сервера.

1 голос
/ 02 июля 2011

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...