Где хранить ключ шифрования

Я шифрую данные (индустрия здравоохранения), используя классы шифрования aes в рамках .net. Каковы некоторые из рекомендуемых мест для безопасного хранения ключа? У меня есть это в web.config для разработки, но это не кажется продуктом, достойным, мягко говоря.

Ответы

Ответ 1

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

http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx

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

Ответ 2

Что вам нужно сделать, это скрыть этот ключ где-то, и безопасное местоположение будет находиться внутри базы данных. Предпочтительно другая база данных, чем та, которая содержит ваши данные. Поскольку данные требуют сочетания имени пользователя и пароля, чтобы открыть их, вы просто добавляете второй уровень безопасности в свое приложение. Вашему приложению потребуется войти в базу данных ключей, получить ключ X для приложения Y и затем использовать его. Тем не менее, вам нужно будет хранить строку соединения для этой базы данных.
Даже если вы сохраните только один ключ в базе данных ключей, это было бы полезно. Это заставляет хакера брать больше проблем, чтобы открыть эту базу данных, чтобы найти ключ, прежде чем он сможет получить доступ к данным. Поскольку нет идеальной защиты, ваши возможности ограничены лишь задержкой времени, в течение которого хакеру потребуется доступ.
Шифрование файла web.config или данных внутри него также поможет задержать хакера, но если ключ находится внутри конфигурационного файла, все, что ему нужно сделать, это снова расшифровать его.

Ответ 3

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

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

Ответ 4

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

Затем вы можете рассчитать хэш, когда пользователь вводит пароль и проверяет его.

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

EDIT для тех, кто не хочет прилагать слишком много усилий для понимания USE CASE, который я представил

У Джонни есть некоторые зашифрованные данные AES.
Он хранит свой ключ в голове.
Он хочет сохранить это эй где-то на своем ПК, чтобы автоматизировать доступ.
Он может хранить его как ASCII в web.config.
Но он может хэш, чтобы быть не более ASCII, но хешем.
Во время аутентификации приложение вычисляет хеш-чеки, это правильный ключ, затем использует этот ключ....
Вероятно, мало вероятность столкновения с правильным алгоритмом.

пс. просто отправляю свою точку зрения на эту тему.
Почему вы так чувствительны к слову "хэш"???

РЕДАКТИРОВАТЬ 2
Я знаю, что такое хэш,
Я знаю, что называется так называемым двухсторонним шифрованием....