Хранение ключей шифрования — лучшие практики?
Lua 5.1 и позже определяют макрос LUA_VERSION_NUM для десятичного представления номера версии, например 501 для Lua 5.1. Вы можете сравнить это с макросом, например
#if defined(LUA_VERSION_NUM) && LUA_VERSION_NUM >= 510
lua 5.1 code
#else
older version code
#endif
5 ответов
Один стандартный подход в мире веб-приложения должен разделить ключ и поместить его в различные места. Например, Вы могли бы разделить ключ и поместить часть его в файловой системе (за пределами каталога 'веб-приложений'), часть ее в конфигурации JNDI (или эквивалентный .NET) и часть ее в базе данных. Получение любой единственной части не особенно трудно, если Вы скомпрометированы, например, исследуя резервные носители, или Внедрение SQL, но получая все части потребует намного большего количества работы.
Можно разделить ключ XOR-лугом это со случайными числами того же размера. (Используйте криптографически сильный генератор случайных чисел!) Можно несколько раз повторять этот процесс, если Вы хотите разделить ключ на несколько частей. В конце процесса Вы хотите, например, три частичных ключа, таким образом что p1 ^ p2 ^ p3 = ключ. Вы, возможно, должны были бы base64-закодировать некоторые частичные ключи, таким образом, они могут быть сохранены правильно, например, в свойстве JNDI.
(Существуют более сложные способы разделить ключ, например, n-of-m алгоритм, где Вы не требуете, чтобы все части воссоздали ключ, но это - далеко, в чем Вы нуждаетесь здесь.)
Если можно потребовать, чтобы пользователь активно ввел пароль, существует PBE (основанное на пароле шифрование) алгоритмы, которые преобразовывают пароль в хороший симметричный ключ. Вы хотите найти тот, который требует внешнего файла также. Снова это - случай, который резервные копирования на магнитную ленту или сам пароль не достаточно, Вам нужны оба. Вы могли также использовать это для разделения пароля на две части с JNDI - можно использовать пароль простого текста в JNDI и файле инициализации где-нибудь в файловой системе.
Наконец, независимо от того, что Вы действительно уверены, что можно 'повторно ввести' приложение довольно легко. Один подход должен использовать пароль, полученный выше для дешифрования другого файла, который содержит фактический ключ шифрования. Это помогает изменить пароль, если Вы думаете, что он был поставлен под угрозу, не требуя, чтобы крупное перешифрование всех данных - просто повторно зашифровало Ваш фактический ключ.
Для Вас действительно ли возможно ввести пароль в интерактивном режиме каждый раз, когда приложение запускает? Тем путем Вы не должны хранить ключ или по крайней мере любые ключи (являются ли они симметричными или закрытыми ключами), может быть зашифрован с этим паролем "начальной загрузки".
В противном случае сохраните свой секретный ключ в файле отдельно и измените его полномочия сделать его доступным только для пользователя, запускающего веб-приложение.
Эти подходы являются агностиком платформы. Для более конкретных предложений информация о Вашей платформе была бы полезна.
Между прочим, вектор инициализации должен использоваться только для одного сообщения. И IVS не имеет держаться в секрете, таким образом, Вы могли сохранить его где угодно, но хранение его с одним сообщением, которое использует его, обычно.
Я использовал подход, где мое приложение требует симметричного ключа, когда оно запускается и ищет его в определенном файле. После того как приложение запустило, я удаляю файл. Копия файла сохранена удаленно для любых необходимых перезапусков. Очевидно, этот подход не жизнеспособен, если Ваше приложение имеет частые перезапуски.
Другая альтернатива была бы менеджером сертификата, таким как Windows Certificate Store. Это может сохранить сертификаты и их ключи надежно, и также возможно отметить закрытые ключи как неэкспортные, таким образом, это потребовало бы, чтобы некоторое серьезное взламывание вывело ключ. Ваше приложение могло загрузить свой сертификат из Хранилища сертификатов и смочь назвать операции, чтобы подписать запросы или генерировать новые симметричные ключи. Кроме того, можно присвоить полномочия различным certifcate хранилищам так, чтобы только определенные привилегированные учетные записи смогли бы получить доступ к сертификату.
засуньте его в web.config и зашифруйте тот раздел
Это ТАК вопрос говорит больше о web.config шифровании
Это должно помочь...
http://msdn.microsoft.com/en-us/library/ms998280.aspx
Но, действительно необходимо рассмотреть движение к PKI, если Вы серьезно относитесь к защите Ваших данных.