Как получить два независимых пароля из одной строки?

Question

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

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

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

Это будет то, что происходит, когда пользователь регистрируется:

• пользователь выбирает имя пользователя / пароль ( Пароль A ) и ключ шифрования ( Пароль B ).
• хеш (пароль A) хранится на сервере
• Пароль B нигде не хранится.

, то:

• пользователь вводит Пароль A => Пароль A передается на сервер
• сервер проверяет хеш (пароль A) на пользователя db, предоставляет доступ
• клиент загружает настройки и зашифрованные данные
• Пользователь вводит Пароль B -> зашифрованные данные дешифруются (локально).

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

Я бы хотел использовать два независимых пароля, но спрашивать у пользователя только один.

Первая попытка

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

Недостатком этого является снижение надежности паролей: если предоставленная пользователем строка уже слабая / короткая, пароль A и пароль B будут еще слабее.

Вторая попытка

Другой вариант: использовать предоставленный пользователем пароль в качестве ключа шифрования (Пароль B) и использовать хеш (SHA-256) этого пароля в качестве служебных учетных данных.

Регистрация:

• пользователь выбирает один пароль PASS
• хеш (PASS) передается на сервер
• сервер хранит хеш (hash (PASS)) с именем пользователя в пользователе db

Тогда:

• пользователь вводит PASS
• служба отправляет на сервер пароль A = hash (PASS)
• сервер проверяет хеш (пароль A) на пользователя db, предоставляет доступ
• клиент загружает настройки и зашифрованные данные
• клиент расшифровывает зашифрованные данные с помощью пароля B = PASS.

Это означает, что

1. хеш пароля шифрования передается по сети 2)
2. хеш (хэш (ключ шифрования)) теперь хранится на сервере, то есть вместе с зашифрованными данными

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

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

Answer 1

Я бы пошел другим путем. Использование openid для аутентификации в вашей системе. Таким образом, вам не нужно передавать пароль на ваш сервер вообще.

При первом подходе вы должны передавать только хэш.

Answer 2

Совет по использованию схемы безопасного пароля правильный. Что вы можете сделать, это сделать небольшое изменение перед передачей текста пользователя в схему паролей. Если пользователь вводит «пароль», тогда передайте «passwordLOCAL» локальной схеме паролей и «passwordREMOTE» удаленной схеме паролей.

Это позволяет пользователю вводить один пароль, но при этом иметь два разных локальных и удаленных пароля. На самом деле не используйте «LOCAL» и «REMOTE», конечно, слишком небезопасно. Используйте две разные случайные строки, как две разные соли.

Answer 3

Как подсказал @Tim в своем ответе - не создайте новую схему аутентификации пользователя (ваша собственная комбинация идентификатора пользователя и пароля).

Исходя из того, для чего вы это строите, у вас в основном есть 2 варианта:

• Если это в корпоративном внутреннем приложении, просто интегрируйте его в Active Directory или какую-либо внутреннюю базу данных пользователей и сервер аутентификации.у вас есть
• Если это общедоступный, используйте OpenID (если вам нужна только аутентификация ) или OAuth , если вам также нужна авторизация.

Обратите внимание, что ваше приложение не должно иметь веб-интерфейс для их использования.(Вам нужен доступ в интернет, хотя).См. этот вопрос для получения более подробной информации

Для ключей шифрования используйте некоторую функцию Функция получения ключа (также известную как PRF+) для получения ключа - предпочтительно сдругие компоненты, а также.Передайте PRF / KDF, например, следующее (сцепленное):

• Уникальный идентификатор пользователя из аутентификатора ( OpenID , AD, как угодно)
• system-широкая строка идентификатора приложения (например, Francescos secureapp keypad)
• на пользователя случайные данные, хранящиеся вместе с пользовательской информацией (например, 16 байтов из системного случайного источника)
• пользователь шифрование пароль - это единственный пароль , о котором вам нужно заботиться.

Это несколько похоже на расчет полезной нагрузки AUTH в протоколе IKEv2

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

Кроме того, нехранить пароль шифрования пользователя на стороне сервера.Клиент должен всегда запрашивать его (или кэшировать на определенное количество времени) у пользователя и отправлять его (в обычном или хешированном виде) по зашифрованному каналу на сервер всякий раз, когда запрашивает что-то, что требует [en | de] cryption.

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

Answer 4

Если я правильно помню, LastPass использует эту систему:

1. Пользователь вводит адрес электронной почты и пароль
2. Пароль хешируется, а хэш используется как ключ длязашифровать конфиденциальные данные пользователя
3. Хэш пароля + электронная почта хэшируется во второй пароль, который используется для входа на сервер и загрузки зашифрованного большого двоичного объекта данных

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

Answer 5

Вы можете сгенерировать и сохранить IV (или два, если необходимо) на сервере и отправить его клиенту в HMAC. Это создает ключи шифрования, которые необходимы.