Защитить PII в базе данных веб-приложения путем шифрования открытым ключом в сочетании с закрытым ключом, защищенным паролями пользователя?

Question

Цель:

Я хотел бы разрешить пользователям создавать вопросы и собирать информацию от других пользователей в пользовательском веб-приложении (PHP / MySQL в среде хостинга) и защищатьсобранные данные.

Справочная информация:

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

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

Предлагаемое решение:

Предполагая, что встроенные функции MySQL AES_ENCRYPT()/AES_DECRYPT() используются для шифрования таблицы PII, парольная фраза будетнеобходимо хранить в учетной записи хостинга, поэтому, если учетная запись хостинга будет скомпрометирована, данные могут быть легко прочитаны.

Так как пароли пользователей хорошо защищены (хешированы солью), я думаю о захватеих незашифрованный пароль во время аутентификации, шифрования и сохранения в сеансе PHP до выхода пользователя из системы.

Комбинация с открытым / закрытым ключом будет создана для каждого пользователя, причем закрытый ключ защищен паролем с помощью пароля пользователя + соль.

Затем, когда данные PII на основе пользовательских вопросов этого пользователядобавленный в БД, открытый ключ пользователя будет использоваться для шифрования PII, который он собирал через приложение.Когда данные читаются (только когда пользователь вошел в систему), данные будут незашифрованы с помощью закрытого ключа пользователя (который разблокируется с помощью его пароля + соли).

преимущества Я вижу:

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

Недостатки Я вижу, что:

1. пароли пользователей сохраняются в восстанавливаемой форме при входе в систему.
2. пользователи, которые забывают свои пароли, теряют доступ к своим данным.
3. каждый относительноНебольшой бит данных из-за шифрования займет гораздо больше места в БД.

Мой вопрос: Есть ли лучший способ сделать это?

Answer 1

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

Более того * MySQL AES_ENCRYPT() является полным мусором по нескольким причинам. Он использует режим EBC, и вот хороший пример того, почему это дерьмо:

Исходное изображение:

EBC Mode (это то, что использует mysql AES_ENCRYPT()):

Но если взломанная база данных, злоумышленник собирается победить AES_ENCRYPT(), включив журнал запросов .

Следует избегать использования пароля пользователя для шифрования, вы должны использовать одноразовый шифровальный код. Если вы используете пароль, убедитесь, что вы используете функцию String2Key. Вы также должны использовать режим CBC или CMAC с случайным iv . Я действительно не понимаю, как асимметричная криптография может помочь. Асимметричная криптография очень медленная, интенсивная память. Эти данные, которые он защищает, становятся менее безопасными, когда злоумышленник контролирует сообщение, потому что вы можете сравнить шифрованные текстовые сообщения. Вот почему случайный IV важен , и в асимметричном мире у вас нет такого уровня защиты.

Генерация ключей должна выглядеть примерно так: $key=string2key($base_nonce.$salt.$user_password)

Убедитесь, что выходные данные вашей функции string2key имеют тот же размер, что и ваше пространство клавиш. Таким образом, AES 128 нуждается в 128-битном ключе. Каждый пароль должен иметь свой собственный $salt, а $base - это криптографический одноразовый номер, хранящийся в текстовом файле. (Злоумышленнику придется прочитать этот файл, прежде чем он сможет взломать ключ, если это значение велико, например, 128 бит, то это спорная точка.) Каждое сообщение должно иметь свой собственный $iv, и это значение также должно быть одноразовым шифрованием (аналогично в соль). Я бы сгенерировал $salt, $iv и $base_nonce из /dev/urandom. IV может храниться в виде простого текста в столбце в вашей базе данных вместе с зашифрованным текстом.

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

Лучшая защита от правовой угрозы - это строгие условия, написанные опытным юристом.

Answer 2

Одна из проблем, с которой я столкнулся, заключается в следующем. Часть «все пользователи, не вошедшие в систему, будут в безопасности», слишком оптимистична. Защищая закрытый ключ паролем пользователя, вы открываете себя к различным атакам с использованием перебора паролей. Не только для текущих сессий, но и для всех. Один из эффективных способов - просто перечислить, скажем, 100 самых распространенных паролей, и просто опробовать их против всех пользователей. Атакующий обязан раскрыть некоторые ключи. (Я предполагаю, что вы либо храните случайную соль для каждого пользователя с записью пользователя, которую может видеть злоумышленник, либо у вас есть секретная соль, которую злоумышленник смог получить с помощью компрометации.)