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

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

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

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

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

Хорошо, так где они должны храниться? Файловая система? Другая база данных?

Ищете какое-то направление.

Ответы на вопрос(2)

я хотел бы использоватьRegistry Keys protected by ACLТаким образом, только учетная запись, под которой работает ваш пул приложений, может читать их.

 20 авг. 2013 г., 13:05
И поскольку appPoolAccount является тем, который читает regKeys и также олицетворяет веб-вызовы, то хакер может использовать appPoolAccount для доступа к regKeys, если существует проблема безопасности с вашим веб-сервером. И ваша база данных может быть расшифрована. Так что это не оптимальное решение, которое я боюсь.

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

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

Да, это добавляет накладных расходов. Да, это относительно дорого. Но стоит ли это, если у вас есть конфиденциальные данные, такие как данные кредитной карты пользователя? Вы держите пари, что это так.

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

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

 20 авг. 2013 г., 13:07
& GT; & GT; & quot; Во-первых, вы можете попытаться скрыть это & quot; : Безопасность из-за неясности не нужна ... извините

Ваш ответ на вопрос