Двухключевое шифрование / дешифрование?

Question

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

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

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

Есть идеи?

Answer 1

Непонятно, к чему вы стремитесь, поэтому совет по его реализации сложен.

Стандарты, такие как PGP и S / MIME, шифруют каждое сообщение новым симметричным ключом.Эти ключи затем шифруются для каждого получателя сообщения.Таким образом, вместо дублирования сообщения (которое может быть очень большим) для каждого получателя, каждый получает один и тот же зашифрованный текст, и только ключ (который является маленьким) дублируется, но шифруется по-разному для каждого получателя.

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

Answer 2

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

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

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

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

Answer 3

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

Защита конфиденциальных данных - это хорошо.Сейчас:

• Чьи это данные?(ваш, ваш пользователь или третье лицо?)
• От чего его нужно защищать?(раскрытие, коррупция (случайное или преднамеренное ...)
• Кому это нужно, чтобы защитить от
  • Незавершенные стороны, само собой разумеется.
  • Вам нужно / хотитеизбегать доступа к открытым текстовым данным самостоятельно (полезно для отрицания),
  • Нужно ли защищать данные вашего пользователя от того, что они будут видны третьим лицам,
  • или данные третьих лиц от пользователя,
  • Или ваши данные от пользователя или третьей стороны?
• Какие вероятные атаки?
  • Нужно ли защищать в случае, когдасервер полностью взломан?
  • Нужно ли защищаться от атаки на уровне приложения, когда пользователь просто получает доступ к некоторым, но не ко всем доступным данным (например, к базе данных SQL, но не к файловой системе)?
  • Будет ли объем данных достаточно маленьким, чтобы злоумышленник мог угадать и просто проверить, правильно ли он понял? (Короткие пароли, числа, простые слова, текст в фиксированной формевсе кандидаты)
  • Будет ли злоумышленник знает открытый текст, с помощью которого можно атаковать?
• Лучше, чтобы данные исчезали (или повторно извлекали данные)если пользователь забывает свой пароль, или стоит увеличить риск раскрытия данных, чтобы избежать такой стоимости?

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

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

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

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

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

Answer 4

Это вопрос, который я задумал о себе, и, как я понимаю, доступны следующие опции (наиболее безопасным является вариант № 1):

1. Не предоставляют функции сброса пароля - если они забыли свой пароль, они блокируются.

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

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

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

Таким образом, преимущества каждого варианта следующие:

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

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

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

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

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

Answer 5

По сути, если вы что-то шифруете и теряете ключ шифрования, вы облажались.

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

Так что здесьзадайте себе несколько вопросов:

1. Если кто-то скомпрометирует мою базу данных, допустимо ли для них иметь доступ к этим данным?
2. Что если кто-то скомпрометирует весь мой стек приложений?

Если ответы на два вышеупомянутых вопроса «нет», то материал ключа должен храниться у пользователя.И они потеряют доступ к своим данным, если потеряют ключ.

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

Answer 6

1. Генерация случайного ключа сеанса.
2. Используйте ключ сеанса для шифрования данных.
3. Зашифруйте случайный ключ любым количеством пользовательских паролей, которые вам нужны.

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

Answer 7

Почему вы используете разные ключи для каждого пользователя?

Если вы выберете один ключ, с ним будет намного проще работать.

Храните ваш ключ шифрования вне базы данных.

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