Аутентификация с помощью соленого пароля

Question

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

У меня сценарий клиент/сервер. Клиент - это приложение на настольном компьютере (а не на веб-сайте, а не на http-сервере).

Как я могу это достичь? Я пришел только так далеко: я генерирую соль + хеш на клиенте, формирую mcf из него и отправляю его на свой сервер. Сохраните файл mcf в базе данных. Я не отправлял пароль, просто хэш, который практически бесполезен (поскольку скриншот должен быть достаточно сильным, и для его изменения потребуется несколько миллионов лет). Как я могу теперь зарегистрировать пользователя в моем сервисе, не отправляя пароль открытого текста на сервер, чтобы сравнить его? Я не могу перефразировать его, так как это приведет к другому хешу из-за другой соли? Мне нужно отправить соль клиенту, ввести пароль, отправить хэш на сервер, сравнить его и отправить обратно токен аутентификации.

Как я могу это достичь? Действительно ли аутентификационный токен защищен? Наверное, его можно просто использовать для олицетворения любого?

Answer 1

не хотите отправлять пароль в незашифрованном виде по проволоке,

Хорошая идея, но если соединение не зашифровано (что-то вроде SSL/TLS), то, что вы посылаете является простой текст. Если вы используете хэш-клиент на стороне клиента и отправляете его по сети, то это пароль. Некоторые скажут, что здесь нет никакой пользы, но это не позволяет пользователю разоблачить свой фактический пароль, который они, вероятно, повторно используют на других сайтах. (read more here)

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

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

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

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

Вы должны использовать асимметричное шифрование, где только сервер может расшифровать данные.

Answer 2

Существует короткий ответ на ваш вопрос, потому что есть так много подводных камней, которые могут произойти, если вы сделаете это неправильно. Но, как говорит Грей, вам нужна защита TLS.

У меня есть два источника, которые дают вам подробные объяснения по правильному пути для этого , если вы хотите обработать обработку на стороне клиента.

1. Method to Protect Passwords in Databases for Web Applications. Если вы не хотите понимать все обоснования, просто перейдите к разделу 4, чтобы увидеть реализацию (где PPF = ваш scrypt).
2. Client-Plus-Server Password Hashing as a Potential Way to Improve Security Against Brute Force Attacks without Overloading the Server.

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