PHP MySQL - на лету шифрование, расшифровка данных без сохранения ключа - PullRequest
1 голос
/ 27 марта 2011

Я прошел несколько SO вопросов по этому поводу, и мой подход немного отличается с точки зрения желания зашифровать данные.Вот что я хочу сделать ..

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

Теперь эти данные хранятся в необработанном формате в базе данных (mysql).

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

Таким образом, в принципе, вот как это будет работать.

1) Выберите запись клиента в mysql

2) Получите ключ шифрования через поле ввода

3) Обновите запись mysql, зашифровав данные

Итак, вот мои 2 вопроса ...

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

2) Как настроить систему шифрования?Если бы я использовал функцию mysql AES_ENCRYPT (учтите, что длина данных может варьироваться, например, адрес, адрес электронной почты или другая информация о клиенте)

Ответы [ 4 ]

2 голосов
/ 27 марта 2011

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

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

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

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

2 голосов
/ 27 марта 2011

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

Лучшим вариантом PHP для криптографии с открытым ключом является стандартное расширение OpenSSL , в котором используется стандартная RSA система.

Ключи могут быть сохранены в PEM-кодированном файле (fancy base64), для которого требуется пароль для разблокировки. Именно эту ключевую фразу вы хотели бы предложить пользователям, а не фактический ключ. Это удачно, поскольку защищенные ключи RSA довольно велики и не могут быть точно запомнены. Это также позволяет безопасно хранить закрытый ключ на сервере.

Кроме того, это должно быть очевидно, но вы, вероятно, хотите убедиться, что вы обслуживаете свое приложение по SSL, даже если это полностью внутреннее приложение. Защита данных без защиты транспорта данных глупа.

1 голос
/ 28 марта 2011

Я не уверен, что это сработает для вас, но в прошлом месяце на RSA была компания с Transparent Data Encryption для mySQL в Linux. У них также есть способ управлять и хранить ключи так, чтобы они были отделены от данных. Подходит для PCI, HIPAA-HITECH и т.д ...

Они шифруют на диск, когда mySQL пишет, и дешифруют, когда запрашиваются данные. Никаких изменений в приложении или структуре данных вообще. Компания Gazzang. Просто поищите их или ознакомьтесь с RSA Innovation Sandbox 2011.

Надеюсь, это поможет

1 голос
/ 27 марта 2011

Вам также следует подумать о том, как сменить пароли в случае атаки. Идея @Charles поддается этому, но использование RSA для шифрования фактических данных, вероятно, будет медленным (алгоритмы с открытым ключом намного медленнее, чем симметричные шифры).

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

Теперь вы можете сменить пароль в любое время без необходимости менять ключ шифрования и без повторного шифрования всех данных.

AES - хороший выбор для реальной работы шифрования. Это быстро и хорошо изучено.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...