MySQL зашифровал столбцы

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

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

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

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

INSERT INTO secure_table VALUES (
  1,
  AES_ENCRYPT(
    'plain text data',
    CONCAT(@application_password, @user_password))
);

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

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

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

Разъяснить один из ответов, упомянутых в вопросе: "ключ пользователя/приложения" является случайным образом сгенерированным закрытым ключом, который используется для шифрования данных. Закрытый ключ никогда не изменяется (если он не поставлен под угрозу). Вы шифруете и снабжаете закрытый ключ паролем. Так как закрытый ключ намного меньше, чем данные, намного более дешево изменить пароль: Вы просто дешифруете закрытый ключ со старым паролем и повторно шифруете его с новым паролем.

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

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

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

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

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

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

Скажите, что пароль является pass1. И существует набор записей, зашифрованных с ключом, сгенерированным от этого. Если пользователь теперь изменяет пароль к pass2, у меня нет способа дешифровать данные, которые были зашифрованы с помощью pass1

Ключ должен был бы быть зашифрован обратимым способом, так, чтобы он мог быть дешифрован с помощью pass1 и повторно зашифровал использование pass2.

Подводить итог:

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

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

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