На данный момент я работаю над проектом, который будет обрабатывать некоторые весьма конфиденциальные личные данные, хотя это не номера backaccount, это все еще конфиденциальная личная информация, и я хочу сделать все, что я могу сделать, чтобы зашифровать и сохранить эту информацию внутри mysql как безопасно насколько это возможно. Поэтому сейчас я интенсивно ищу некоторые меры безопасности, которые могут справиться с этой конфиденциальной информацией.
Один простой способ, который я нашел для шифрования / расшифровки строк и текстовых блоков, будет использовать mcrypt. Но когда я просматриваю mcrypt здесь в stackoverflow, я заметил, что многие люди говорят, что mcrypt после этого не является безопасным.
Так что теперь мне интересно, насколько это безопасно? Требуется ли много навыков взлома, скажем, экспертных навыков, взломать и расшифровать сохраненную информацию, если ключ хранится надежно? Нужно ли мне бояться, что хакер с небольшими навыками может расшифровать зашифрованную информацию, которую я собираюсь хранить на сервере mysql? Итак, какие навыки необходимы для взлома зашифрованной информации, зашифрованной с помощью mcrypt?
Если Mcrypt недостаточно подходит для использования, какие хорошие альтернативы, которые не сложны с использованием расширений gnupg?
Небольшой путеводитель, который вы могли бы выполнить, чтобы избежать нескольких подводных камней и применить некоторые рекомендации.
Это будет подвергать риску разоблачение открытого текста, если противнику удастся перехватить два или более сообщения во время транзита с использованием того же ключа и IV.
Основная причина не использовать ECB заключается в том, что в этом режиме происходит утечка информации о дублирующих блоках открытого текста, которые могут подорвать ваш кодированный поток данных.
OFB и CTR лучше, но они страдают от вышеупомянутой проблемы безопасности использования одной и той же комбинации клавиш IV + более одного раза.
CFB и CBC являются наиболее устойчивыми к повторному использованию ключа IV +, но отдельные сообщения с одним и тем же общим префиксом будут вытеснять длину указанного префикса. Кроме того, CFB просачивает разницу в первых неидентичных блоках открытого текста.
Убедитесь, что у вас есть надежный ключ шифрования
Он не должен выбираться из ASCII для печати (например, не «мой сверхсильный секретный ключ»); PBKDF2 был бы предпочтительнее (вскоре его можно будет поддерживать, до тех пор, пока он будет использоваться Google). Должно быть очевидно, что этот ключ должен быть сохранен; если вы потеряете его, пока до свидания данные.
Используйте хороший источник энтропии для генерации вектора инициализации.
Mcrypt имеет возможность использовать MCRYPT_DEV_RANDOM или MCRYPT_DEV_URANDOM при вызове
mcrypt_create_iv().
Надеюсь, что это поможет вам 🙂