Сохранение дешифруемого пароля

Я знаю, что подобный вопрос задавался миллион раз, но я не смог найти ответ, который соответствовал бы моим потребностям.

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

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

Вопрос в том, как их хранить.

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

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

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

Есть ли лучший способ сделать это, чтобы сохранить эти данные для входа?

Если для вас это важно, приложение будет на PHP, а база данных — на Oracle.


person BeRightBack    schedule 17.07.2018    source источник
comment
Такие сервисы, как passpack.com, занимаются расшифровкой данных только на стороне клиента…   -  person CBroe    schedule 17.07.2018
comment
Если вы впервые имеете дело с шифрованием, я бы дважды подумал о создании этого или покупке того, что уже существует. Есть несколько отличных менеджеров паролей, которые подверглись тщательной проверке.   -  person Joe    schedule 17.07.2018
comment
Согласованный. Это очень сложная проблема для безопасной реализации, и она определенно не должна быть чьим-то первым криптографическим проектом для хранения чужих паролей. Если вы хотите начать изучать связанные с этим проблемы, я рекомендую технический документ 1Password по этому вопросу. 1password.com/files/1Password%20for%20Teams%20White%20Paper. pdf. (Мне также очень нравится 1Password как хранилище паролей, но есть много хороших продуктов.)   -  person Rob Napier    schedule 17.07.2018
comment
Купите хорошо проверенный менеджер паролей, не сворачивайте свой собственный. Обеспечить правильную безопасность очень сложно даже для опытных криптографов, и в результате криптографического сбоя будут раскрыты все пароли, что приведет к катастрофе.   -  person zaph    schedule 17.07.2018
comment
Да, это мой первый раз с шифрованием на таком уровне. И во-вторых, безопасность здесь не является проблемой, потому что в реальной ситуации приложение (и база данных) будут доступны только из нашей внутренней сети (не через Интернет) и только пользователями, которые действительно могут видеть данные. Теперь у этих пользователей есть файл excel на их компьютере с паролями, а пароли известны всем нам.. Так что в основном все, что я делаю, это повышение безопасности, а не проблема безопасности :) Но я хотел бы сделать это как можно лучше. . Конечно, покупка уже готового решения более безопасна, но я пытаюсь здесь учиться.   -  person BeRightBack    schedule 18.07.2018


Ответы (1)


Я бы просто использовал симметричное шифрование. Стандартные шаги:

  • Получить симметричный ключ из введенного пользователем пароля (например, PBKDF2 или scrypt)
  • Зашифруйте данные, используя AES-128-CBC или лучше с хорошим случайным IV.
  • HMAC результат (например, HMAC_SHA256) или просто используйте режим AES GCM

Сохраните IV+зашифрованный текст+MAC в базе данных.

В наши дни все это может работать в браузере (см. crypto-js и aes-js). Таким образом, сервер никогда не увидит пароль в виде открытого текста (не уверен, что это требование).

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

person rustyx    schedule 17.07.2018
comment
Вероятность того, что OP правильно защитит менеджер паролей, ничтожно мала, поэтому правильный ответ — не делать. - person zaph; 17.07.2018
comment
Если я получаю симметричный ключ из пароля пользователя, то для каждого сервера я должен хранить разные пароли для каждого пользователя? Кажется, много работы, когда меняется пароль для сервера (изменение пароля для каждого пользователя, использующего все это)? Кажется, проще использовать учетные записи пользователей, чтобы разрешить доступ к информации, которую может видеть этот пользователь, и каким-то образом использовать приложение для шифрования и расшифровки данных, поэтому при изменении пароля мне нужно изменить его только один раз. - person BeRightBack; 18.07.2018
comment
Ну в таком случае можно и не шифровать ничего. Если сервер содержит ключ шифрования и зашифрованные данные, то при его взломе зашифрованные данные легко расшифровываются. - person rustyx; 18.07.2018
comment
Вот почему у меня возникла идея, что база данных имеет зашифрованные данные, а приложение имеет ключ шифрования. Таким образом, вы можете получить доступ к базе данных, но не сможете расшифровать данные. - person BeRightBack; 18.07.2018
comment
Я вижу, я думаю, вы неправильно понимаете процесс получения ключа. Из того же пароля вы все равно получите тот же ключ. Вывод ключа необходим для замедления грубой силы. Это все. - person rustyx; 18.07.2018