Как мне получить ключ и вектор инициализации для моих записей в зашифрованной базе данных AES?

Question

Я создал систему CMS, позволяющую пользователям создавать и управлять онлайн-формами в приложении моего клиента в интрасети.

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

Все хорошо, но теперь, перед выпуском, я мог бы сделать с рулем относительно shared secret и salt.

Моя оригинальная идея состояла в том, чтобы сделать (динамический) shared secret путем объединения идентификатора (на основе GUID) Form, содержащего зашифрованное поле, с идентификатором (опять же на основе GUID) Question, который является полем для ответа:

FormId:QuestionId

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

QuestionID:FormID.

Я новичок в этом деле, поэтому не уверен, что это разумная стратегия или мне следует заняться этим как-то иначе?

Answer 1

Соль должна быть случайно сгенерированным значением. Его цель - сделать атаки по словарю / перебором более трудными для выполнения. В Википедии есть хорошая статья о криптографических солях: http://en.wikipedia.org/wiki/Salt_(cryptography)

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

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