php шифрование php кода
Шифрование текста на php
Добрый день!
Сегодня я расскажу о моем механихме шифрования.
Не знаю — может он ненадежный, может его уже кто-то изобрел, как говорится, «я хз, мне норм».
Итак, приступим.
Сначала шифрование. Для начала берем строку, который нужно зашифровать, переводим его в base64 (так как base64 ключ состоит только из символов a-z, A-Z, 0-9).
Затем с каждого символа получаем md5-хэш, для удобства кладем в массив.
С каждого хэша берем символ №3,6,1,2 (можно другие, я решил что эти подойдут) и склеиваем их.
Чтобы расшифровать проходимся циклом по коду, заменяем хэш[3,6,1,2] на символ, которому он соответствует.
Ну, и потом декодируем из base64.
Код:
Код самой формы не буду показывать, там все просто.
Слово «Хабр», зашыфрованное ключом «12345» будет «739ef7fc5215e83e5215b8345a02e83e706a8fff5a025e2f5215618bfa54505b52155e2fec2755e2dc07a1106837c7fe29caa11052151c34739ef7fc5215e83e5215b834f9b77ca1706ac7fe65b765b7», а «habr» с тем же ключом будет «7375314fc971f7fca334f9b765b765b7».
Думаю не надо объяснять что base64 с кириллицы длиннее, чем с латиницы.
Ну вот и все.
Демка тут.
О песочнице
Это «Песочница» — раздел, в который попадают дебютные посты пользователей, желающих стать полноправными участниками сообщества.
Если у вас есть приглашение, отправьте его автору понравившейся публикации — тогда её смогут прочитать и обсудить все остальные пользователи Хабра.
Чтобы исключить предвзятость при оценке, все публикации анонимны, псевдонимы показываются случайным образом.
О модерации
Не надо пропускать:
Обратимое шифрование по ключу на PHP
Задача надежного шифрования текстовой информации часто встречается при программировании сайтов. В зашифрованном виде бывает необходимо хранить не только пароли, но и другую информацию. Недавно такая задача встала и у меня. Мне нужна была более-менее надежная функция обратимого шифрования текста по ключу. Почему по ключу? Дело в том, что шифрация без ключа может быть взломана, т.к. большинство алгоритмов шифрования можно найти в интернете и подобрать способ, чтобы получить исходные данные, а шифрация с ключом гораздо более надежная.
Обратимое шифрование на PHP 5 библиотекой MCrypt
Поискав по интернету я нашел целых 2 достаточно коротких в плане количества кода и в тоже время очень надежных способа обратимого шифрования по ключу, которые использует встроенную в php библиотеку Mcrypt.
На подавляющем большинстве хостингов данная библиотека сразу же идет вместе с php. Но если вы администрируете свой сервер и данной библиотеки почему-то вдруг не оказалось в составе php, вы всегда можете ее доустановить командой apt-get install php5-mcrypt для Debian-подобных систем (в т.ч. Mint, Ubuntu) или yum install php-mcrypt для RedHat-подобных систем (в т.ч. Fedora, openSUSE, CentOS) или любым другим способом, который вам нравится (через dpkg, rpm, yast и т.д.).
Затем в папке /etc находите папку php, содержащую ini-файлы расширений, загружаемых php по-умолчанию. Посмотреть путь до этой папки можно в php.ini в разделе «Dynamic Extensions». Это может быть папка /etc/php или /etc/php5/mods-available/ или как у меня на сервере /etc/php.d (вообщем, зависит от настроек php). В этой папке должен присутствовать файл mcrypt.ini. Если его там нет, тогда создайте его с таким содержимым:
; Enable mcrypt extension module
extension=mcrypt.so
После этого можно включить расширение командой php5enmod mcrypt, а затем перезапустить сервер /etc/init.d/apache2 restart для Debian-систем или service httpd restart для RedHat систем. Разумеется, все описанные действия выполняются с правами root-а.
Итак, теперь приведу примеры 2-х способов шифрования по ключу, которые я нашел для себя в интернете.
1-й способ. Обратимое шифрование по произвольному ключу.
2-й способ. Очень надежное обратимое шифрование по шестандцатиричному ключу.
Внимание! Ключ должен быть шестандцатиричным (символы 0123456789ABCDEF) длиной 32 или 64 символа.
Обратимое шифрование на PHP 7 библиотекой OpenSSL
Функции библиотеки Mcrypt, такие как mcrypt_encrypt и mcrypt_decrypt считаются устаревшими и не рекомендуют их использовать. Начиная с PHP 7.2 библиотеку Mcrypt перенесли в PECL. Вместо MCrypt предлагается использовать openssl_encrypt и openssl_decrypt из библиотеки OpenSSL.
Если всё же хотите подключить MCrypt в PHP 7.2 или выше, чтобы использовать ее функции шифрования, тогда можете посмотреть эту статью.
Однако, вернемся к библиотеке OpenSSL. Эта библиотека содержит множество различных методов и алгоритмов симметричного и асимметричного шифрования. Пока что приведу один пример шифрования этими функциями, взятый с php.net а в будущем, доработаю статью, добавив еще примеры.
Обратите внимание : этот алгоритм будет работать начиная с PHP 5.6 и выше. На предыдущих версиях будет выдавать ошибку из-за функции hash_equals, которая осуществляет сравнение строк нечувствительное к атакам по времени (подробнее про атаки по времени можете почитать на википедии).
Другими альтернативами для шифрования на PHP 7+ являются библиотеки: Libsodium и defuse/php-encryption.
Книги по теме:
Посмотреть все книги по программированию
Комментарии к статье:
Шифрование данных на PHP
Дата публикации: 2013-11-18
От автора: в данном уроке мы с Вами рассмотрим шифрование данных стандартными средствами языка PHP. Так как при создании различных скриптов очень часто возникает задача шифрования данных. К примеру, важную информацию, которую необходимо сохранить в куках, можно зашифровать для повышения безопасности сайта.
Введение
В данном уроке мы с Вами не будем рассматривать все теоретические моменты процесса шифрования данных, так как для этого понадобиться несколько уроков. Мы изучим только основы, но их полнее будет достаточно, что бы Вы смогли зашифровать данные и выполнить их расшифровку.
Шифрование бывает двух видов: однонаправленное – когда данные можно только зашифровать, а расшифровать нельзя (к примеру, шифрование md5) и двунаправленное – когда есть возможность, как зашифровать, так и расшифровать данные. В данном уроке мы будем использовать двунаправленное шифрование. Для работы с шифрованием в языке PHP разработано расширение под названием mcrypt, которое позволяет шифровать данные используя различные алгоритмы шифрования (шифры).
Бесплатный курс по PHP программированию
Освойте курс и узнайте, как создать динамичный сайт на PHP и MySQL с полного нуля, используя модель MVC
В курсе 39 уроков | 15 часов видео | исходники для каждого урока
Так как шифрование данных – это целая наука и при создании собственного алгоритма, Вы можете не учесть множество различных моментов. Что приведет к уязвимости зашифрованных данных и возможно к взлому их злоумышленниками. Лучше всего использовать уже готовые алгоритмы, которые очень надежны и, так сказать, проверены временем. Алгоритм шифрования – это собственно то, каким образом будут зашифрованы данные.
Каждый алгоритм поддерживает различные режимы шифрования. Режим шифрование – это метод применения блочного шифра, который позволяет преобразовать последовательность блоков исходного текста, который шифруется, в последовательность блоков зашифрованных данных. При этом при шифровании могут использоваться данные других блоков. Мы с Вами будем использовать один из лучших режимов шифрования — MCRYPT_MODE_CFB. Данный режим, еще называют режимом обратной связи по шифрованному тексту, т.е — это такой вариант использования блочного шифра, при котором для зашифровки следующего блока текста используется результат зашифровки предыдущего блока.
Полную документацию, по расширению mcrypt можно посмотреть на официальном сайте интерпретатора языка PHP, по адресу: //us3.php.net/manual/ru/book.mcrypt.php
Полный перечень всех алгоритмов шифрования можно посмотреть по следующей ссылке: //us3.php.net/manual/ru/mcrypt.ciphers.php
Ну и конечно все режимы шифрования доступны здесь: //us3.php.net/manual/ru/mcrypt.constants.php
Теперь давайте приступим к шифрованию данных.
Шифрование данных
Для начала давайте создадим небольшую форму для ввода текста, подлежащего шифрованию:
Кодирование и декодирование PHP кода
Я занимаюсь восстановлением исходников PHP из закодированного вида.
В этой статье я расскажу о том, как обстоят дела с кодированием и декодированием PHP в настоящее время.
Очень краткий ликбез по внутреннему устройству интерпретатора PHP
При выполнении PHP-скрипта, он парсится и компилируется в опкоды внутренней виртуальной машины PHP.
Из каждого файла PHP получаются:
— массив классов: в каждом классе — информация о классе, свойства класса и массив методов класса
— массив функций
— «тело скрипта» — код вне классов и функций
Для краткости, всю внутреннюю структуру скомпилированного файла, готового к выполнению, в этой статье я называю «опкодами«.
Сами опкоды (операции внутренней виртуальной машины PHP) внутри какой-нибудь функции выглядят так:
Важный момент: файлы в скомпилированном виде достаточно сильно отличаются даже между подверсиями интерпретатора PHP. Оно и понятно: сам для себя скомпилировал — сам и выполнил.
Как работают энкодеры
Существуют два принципиально разных типа энкодеров.
Первые — работают исключительно средствами самого языка. Они делают код нечитаемым с помощью base64-кодирования, zip-ования, разных манипуляций со строками, и все в конце концов используют функцию eval(). Все это очень похоже на обфускаторы в Javascript. Выглядит это как-то так:
Снимается такая защита очень просто, в самых сложных случаях — за несколько часов. Еще один крупный минус — серьезно страдает производительность. Поэтому для серьезного применения такую защиту использовать не рекомендуется.
Второй тип энкодеров использует свои подключаемые модули для интерпретатора PHP, которые называются загрузчиками (loader-ы). В этом случае, как правило, кодируется не сам исходный код, а результаты его компиляции, т.е. внутренние структуры и опкоды. Это уже гораздо более серьезная защита — даже если раскодировать сами опкоды, по ним еще надо восстановить исходный PHP-код. К тому же, с точки зрения производительности, дополнительные затраты на раскодирование часто компенсируются экономией на компилировании кода, т.е. скорость выполнения закодированных скриптов зачастую даже выше, чем у исходного кода.
Во время загрузки интерпретатора PHP, loader-ы энкодеров вешают свои обработчики на функции загрузки PHP-файлов, компиляции и выполнения, для того, чтобы работа с закодированными файлами была бы прозрачной для самого интерпретатора.
Основная сложность для энкодеров — это сделать так, чтобы опкоды, скомпилированные под одной версией PHP во время кодирования, работали бы под другой версией PHP при декодировании. Практически все loader-ы у всех энкодеров после декодирования делают необходимые правки, чтобы обеспечить такую совместимость. Главный игрок на этом рынке — IonCube — в свое время приложил огромные усилия для решения этой задачи, и его loader-ы могут на лету корректно выполнить опкоды от PHP 4.x на PHP 5.x, а по возможности — даже наоборот!
Обфускация
Также, для дополнительной защиты, большинство энкодеров дает возможность обфусцировать идентификаторы: имена переменных, названия функций, классов. Этот процесс, как правило, односторонний — наподобие хэширования, и к тому же в результате часто получаются имена с непечатными символами, которые отлично работают, но которые нельзя использовать напрямую в декомпилированных текстах. Например, как записать функцию с именем… *диктую по байтам* 0x0D, 0x07, 0x03, 0x0B, 0x02, 0x04, 0x06?
Отдельно внимание уделяется тому, чтобы обфусцированные имена работали бы корректно. Например, в коде вызывается функция checkLicense — loader обфусцирует название на лету, получает < 0x0D, 0x07, 0x03, 0x0B, 0x02, 0x04, 0x06 >и ищет уже этот ключ в хэш-таблице с названиями функций.
Zend Guard даже предоставляет run-time функции zend_obfuscate_function_name и zend_obfuscate_class_name, которые позволяют вычислить обфусцированные имена для функций и классов, чтобы облегчить связывание закодированных файлов с незакодированными.
Декодеры наносят ответный удар
Для создания декодера нужны две вещи: получать расшифрованные опкоды и уметь декомпилировать их в исходный код PHP.
Для получения опкодов кому-то пришла в голову светлая идея — сделать свою сборку интерпретатора PHP, которая бы вместо выполнения раскодированного скрипта — отправляла бы его на декомпилирование. Не нужно возиться с чтением формата энкодера и его защитами — loader энкодера сам делает всю нужную работу!
Какое-то время это работало неплохо, потом авторы некоторых энкодеров додумались заменять раскодированные функции заглушками, а реальный код прятать и доставать каждую вызываемую функцию только в момент ее непосредственного выполнения.
В ответ, авторы декодеров стали модифицировать loader-ы от энкодеров, чтобы те не применяли такие заглушки.
Довольно большой минус оказался в том, что для каждой версии PHP у каждого энкодера были свои loader-ы, которые к тому же частенько обновлялись. Приходилось много и часто патчить, хотя и несложно — просто отключить вызов функции-другой.
Это надолго затормозило тех, кто «патчил loader-ы». Во-первых, пришлось долго разбираться, почему вроде бы правильно вытащенные опкоды декомпилируются с ошибками. Во-вторых, тут уже не получалось просто поменять пару байт в loader-е.
На сцену вышли те немногие, кто прикладывал больше усилий — реверсил и разбирался в формате закодированных файлов.
Вторая часть в работе декодера — декомпилирование. Это — сложная, но интересная, чисто алгоритмическая задача.
Когда-то светлые головы написали пару неплохих алгоритмов декомпилирования для PHP. Большинство тех, кто занимается декодированием PHP сейчас, написать свой декомпилятор не могут, поэтому используют те, что есть, с минимальными правками.
Все декомпиляторы в открытом доступе правильно восстанавливают только 90-95%% кода. Остальное приходится исправлять вручную, и тут очень большую роль играют опыт программирования на PHP и опыт декомпилирования, т.к. ошибки возникают обычно типовые.
Подводя итог: никакого полностью автоматического декодирования для основных коммерческих энкодеров пока нет.
Как защититься от декодирования
Ясно, что рано или поздно любой закодированный код будет вскрыт, если это будет нужно. Но зная, как устроена работа декодеров, можно серьезно осложнить этот процесс:
Юридические аспекты
Вообще говоря, декодирование PHP-файлов после коммерческих энкодеров — нелегально. Технически это связано с тем, что для полноценного декодирования нужно декомпилировать и анализировать сами энкодеры, а закон и пользовательские соглашения это прямо запрещают.
На территории Евросоюза есть такая лазейка: разрешается «обеспечивать совместимость экземпляров ПО, которыми вы владеете, и для этого, при необходимости, обходить встроенные системы защиты». При этом прямой запрет на reverse engineering у каждого энкодера все-таки имеет приоритет.
Получается, что «я скачал программу из Интернета, которая достала мне незашифрованные опкоды» или «я использовал специальную сборку интерпретатора PHP, которая сохраняет расшифрованные опкоды» — это условно-легальные способы декодирования. «Условно» — потому что если дело все-таки дойдет до суда, еще непонятно, кто окажется прав.
Понятное дело, что создатели энкодеров предпочли бы, чтобы закодированные файлы никто и никогда не мог бы раскодировать. Но у тех, кто остался с закодированные кодом после недобросовестных фрилансеров, или после исчезновения компании-разработчика (что бывает очень часто), мнение про декодирование — диаметрально противоположное.
Интересные факты и байки
Большая часть энкодеров последние пару лет всего лишь чуть-чуть меняет формат файлов «под капотом», и выпускается под видом новой версии.
При обфускации коротких имен достаточно часто возникают коллизии. Видимо, в таких случаях, тех.поддержка энкодеров просто советует не пользоваться обфускацией.
Фрилансеры настолько часто используют куски кода из документации PHP и со StackOverflow, что словарь, составленный из идентификаторов, взятых оттуда из примеров, позволяет обычно деобфусцировать под 90% всех имен в среднем проекте.
За все время работы я встретил всего лишь пять различных декомпиляторов PHP. Три из них были написаны русскоязычными программистами, еще один — китайцем и еще один — божились, что французом. Мелочь, а приятно — горд за «наших» 🙂
При этом большинство русскоязычных клиентов просит по-свойски сделать работу бесплатно 🙂
Несколько раз получалось так, что декодировать определенный формат файлов мог только я. И одни и те же файлы приходили на декодирование через нескольких разных посредников одновременно.
Особенно меня повеселила такая история: негр с африканским именем и со швейцарским гражданством, разругался с фрилансером-программистом из Австралии, не заплатил ему за работу и остался с парочкой закодированных недоделанных файлов на своем сайте. Долго искал на фрилансерских биржах того, кто их раскодирует, пока наконец один индус не впарил ему свои услуги.
Три недели этот индус кормил заказчика завтраками, а сам усиленно искал реального исполнителя. Параллельно заказчик (жук еще тот) под другим именем и сам продолжал искать других декодировщиков на все тех же фрилансерских биржах. Нашел меня, отдал мне проект… и тут же, буквально через полчаса, ко мне постучался индус и с чувством явного облегчения стал уговоривать сделать и его проект тоже. Я сравнил файлы, и…
Конечно, стоило бы в воспитательных целях взять у обоих 100% предоплаты… но я просто заставил их пообщаться и разобраться между собой.
По итогам, индус до сих пор не забывает поздравить меня с днем рождения.
Заказчик даже дал мне бонус, а сейчас переехал в Эстонию (!) потому что там дешевле жить, и периодически уговаривает меня поучаствовать в каких-то его сомнительных прожектах.
UPD. Пришлось вырезать часть примера с eval-закодированым кодом, потому что Kaspersky выдавал на него предупреждение. Спасибо nokimaro!
Руководство по шифрованию данных на PHP
От переводчика: в процессе программирования никогда не забываю о том, что я опасно некомпетентен в криптографии, и всем советую исходить из этого тезиса (ну, может быть кроме вас и еще вон того крутого парня). Однако, так или иначе, в процессе работы возникают задачи, связанные с защитой данных, и их надо решать. Поэтому я предлагаю вашему вниманию перевод статьи финского разрабочика Timo H, которая показалась мне достаточно интересной и полезной.
Важный update: в комментариях SamDark сделал замечание, что библиотека Mcrypt давно не поддерживается и имеет ряд недоработок, поэтому рекомендуется использовать OpenSSL. Если требуется переписывать имеющийся код, то может помочь эта статья. Кроме того, есть сведения, что Mcrypt может быть удален в PHP7.
Это краткое руководство о том, как избежать распространенных ошибок с симметричным шифрованием на PHP.
Будем рассматривать случай, когда данные обрабатываются на стороне сервера (в частности, шифрование происходит на сервере, а данные могут быть получены, например, от клиента в виде открытого текста, пароля и т.п.), что является типичным случаем для PHP-приложений.
Cведения из этого руководства не стоит использовать для создания шифрованных сетевых соединений, которые имеют более сложные требования. Для таких случаев надо использовать spiped или TLS.
Естественно, рекомендации, приведенные здесь, не являются «единственно возможным способом» организации шифрования на PHP. Цель этого руководства — попытаться оставить поменьше места для ошибок и сложных неоднозначных решений.
Функции шифрования в PHP
Используйте расширения Mcrypt или OpenSSL.
Алгоритм шифрования и его режим работы, одноразовый код (вектор инициализации)
Используйте AES-256 в режиме CTR со случайным одноразовым кодом (прим. перев.: nonce). AES это стандарт, поэтому можно использовать функции любого из расширений — Mcrypt или OpenSSL.
Всегда генерируйте новый одноразовый код. При этом вы должны пользоватся криптографически стойким источником случайных чисел. Немного подробнее о генерации случайных чисел читайте ниже. Одноразовый код не является секретом, и может быть конкатенирован с шифротекстом для передачи и последущей расшифровки.
Одноразовый код должен быть длиной 128 бит (16 байт), просто строка байт без какого-либо кодирования.
Пример использования Mcrypt:
Пример использования OpenSSL:
Убедитесь, что шифрование работает правильно с помощью тестовых векторов (прим. перев.: для AES-256-CTR см. пункт F.5.5 на странице 57).
Для режима CTR существуют некоторые ограничения на суммарный объем шифруемых данных. Возможно вы не встретитесь с этим на практике, но имейте ввиду, что не стоит шифровать более чем 2^64 байт данных одним ключом, безоносительно того одно ли это длинное сообщение или много коротких.
Режим CTR сохраняет стойкость только если не использовать один и тот же одноразовый код с одним и тем же ключом. По этой причине важно генерировать одноразовые коды при помощи криптографически стойкого источника случайности. Кроме того, это означает, что вы не должны шифровать более чем 2^64 сообщений с одним ключом. Поскольку длина одноразового кода 128 бит, важно ограничение на количество сообщений (и соответствующих им одноразовых кодов) 2^128/2 из-за парадокса Дней рождения (прим. перев.: подробнее про парадокс).
И помните, что шифрование не сможет скрыть тот факт, сколько данных вы посылаете. Как пример экстремального случая, если вы шифруете сообщения, содержащие только «да» или «нет», очевидно, шифрование не скроет эту информацию.
Аутентификация данных
Всегда проводите проверку подлинности и целостности данных.
Для этого после шифрования используйте MAC. Т.е. сначала данные шифруются, а затем берется HMAC-SHA-256 от полученного шифротекста, включая собственно шифротекст и одноразовый код.
Если проверка HMAC удачна, можно безопасно производить расшифровку. Если же HMAC не подходит, немедленно завершайте работу.
Ключи шифрования и аутентификации
В идеале использовать ключи, полученные из криптографически стойкого источника случайности. Для AES-256 необходимы 32 байта случайных данных («сырая» строка – последовательность бит без использования какой-либо кодировки).
Если вы полагаетесь на ключ (прим. перев.: ключ вводимый пользователем назовем «пароль»), вводимый пользователем или заданный в конфигурации, то он нуждается в преобразовании перед использованием в качестве ключа шифрования. Используйте PBKDF2 для превращения пароля в ключ шифрования. Подробнее http://php.net/hash_pbkdf2.
Если приложение запущено под PHP версии ниже 5.5, где нет встроеной реализации PBKDF2, то придется использовать собственную реализацию на PHP, пример которой можно найти тут: https://defuse.ca/php-pbkdf2.htm. Имейте ввиду, что полагаясь на собственную реализацию, возможно не получится преобразовать ключ должным образом, как это делает встроенная функция hash_pbkdf2().
Не используйте один и тотже ключ для шифрования и аутентификации. Как сказано выше, необходимо 32 байта на ключ шифрования и 32 байта на ключ аутентификации (HMAC). С помощью PBKDF2 вы можете получить 64 байта из пароля и использовать, скажем, первые 32 байта в качестве ключа шифрования, и остальные 32 байта для ключа аутентификации.
Если у вас пароли хранятся в файле, например, в виде HEX-строки, не перекодируйте их перед тем как «скормить» функциям шифрования. Вместо этого используйте PBKDF2 для преобразования ключей из HEX-кодировки сразу в качественный ключ шифрования или аутентификации. Или используйте SHA-256 с выводом без дополнительного кодирования (просто строка в 32 байта) для хеширования паролей. Использование обычного хеширования паролей дает достаточно энтропии. Подробнее описано в следующих параграфах.
Растяжение ключа
Во-первых, следует избегать использования ключей с низкой энтропией. Но все же, если необходимо использовать, например, пользовательские пароли, то обязательно надо использовать PBKDF2 с большим числом итераций, чтоб максимизировать безопасность ключа.
Одним из параметров PBKDF2 является количество итераций хеширования. И чем оно выше, тем на большую безопасность ключа можно рассчитывать. Если ваш код работает на 64-битной платформе, используйте SHA-512 в качестве алгоритма хэширования для PBKDF2. В случае 32-битной платформы используйте SHA-256.
Однако, невозможно использовать относительно высокое количество итераций в онлайн-приложенях из-за риска DoS-атаки. Поэтому качество ключа не будет столь высоко, как в оффлайновых приложениях, которые могут позволить себе большое число итераций без такого риска. Как правило, для онлайн-приложений подбирают такое количество итераций хеширования, чтоб PBKDF2 отрабатывал не более 100 мс.
В случае, если вы можете использовать пароли с высокой энтропией, не обязательно проводить «растяжение», как для паролей с низкой энтропией. Например, если вы создаете «главный_ключ_шифрования» и «главный_ключ_аутентификации», используя /dev/urandom, то необходимость в PBKDF2 вообще отпадает. Только убедитесь, что используете ключи как последовательности бит, без какого-либо кодирования.
Кроме того, с помощью PBKDF2 несложно получить оба ключа и для шифрования, и для аутентификации от одного мастер-пароля (просто использовать небольшое количество итераций или даже одну). Это полезно, если у вас есть только один «мастер-пароль», используемый и для шифрования, и для аутентификации.
Хранение и управление ключами
Самое лучшее — это использовать отдельное специализированное устройство для хранения ключей (HSM).
Если это невозможно, то для усложнения атаки, можно использовать шифрование файла с ключами или файла конфигурации (в котором хранятся фактические ключи шифрования / аутентификации) с помощью ключа, хранящегося в отдельном месте (вне домашего каталога или корня сайта). Например, вы можете использовать переменную окружения Apache в httpd.conf, чтобы сохранить ключ, необходимый для расшифровки файла с фактическими ключами:
Теперь, если файлы в корне сайта и ниже, в том числе файлы с ключами, будут скомпрометированы (например, при утечке бэкапа), зашифрованные данные останутся в безопаности поскольку ключ, хранящийся в переменной окружения, не был скомпрометирован. Важно помнить, что файлы httpd.conf следует бэкапить отдельно, и не скомпрометировать переменную keyfile_key через, например, вывод phpinfo().
Если вместо параметра конфигурации вы используете файл, то возможно организовать ротацию ключей. В худшем случае, если противник заполучил ваши ключи шифрования и аутентификации, и этот факт остался незамеченным, то ротация ключей с какой-то периодичностью может ограничить его доступ (при условии, что он не может заполучить новые ключи). Такой прием поможет уменьшить ущерб, потому что противник не сможет использовать скомпрометированные ключи бесконечно.
Сжатие данных
В общем случае не стоит сжимать исходный текст до шифрования. Это может дать противнику дополнительный инструмент для анализа.
Например, если вы храните данные сессии в зашифрованных cookie, при этом некоторые из этих данных предоставлены пользователем, а некоторые представляют секретную информацию, противник может узнать дополнительную информацию о секрете, посылая как рядовой пользователь определенным образом сформированные данные и измеряя как меняется длина получаемых шифротекстов.
Текст сжимается более эффективно, если есть повторяющиеся участки. Манипулируя данными пользователя, можно подбирать так, чтоб они частично совпадали с секретными данными. Чем больше совпадение, тем меньший размер шифротекста будет на выходе. Такой тип атаки называется CRIME.
Если у вас нет жесткой необходимости сжимать данные, не сжимайте.
Серверное окружение
Как правило, не стоит размещать требовательные к безопасности приложения на разделяемом сервере. Например, на виртуальном хостинге, где противник может получить доступ к виртуалке на том же физическом сервере, что и вы.
Есть различные причины, делающие разделяемые сервера сомнительным местом для размещения критичных к безопасности приложений. Например, недавно были продемонстрированы атаки между виртуальными серверами: eprint.iacr.org/2014/248.pdf. Это хорошее напоминание, что техники нападения не деградируют, а наоборот оттачиваются и улучшаются со временем. Всегда надо учитывать такие подводные камни.
Консультация эксперта
И последнее, но не по важности, проконсультируйтесь с экспертом, пусть он сделает ревью вашего кода, отвечающего за безопасность.
@plo @veorq Я работаю в криптографии с 1997 года, и до сих пор все мои решения и реализации проходят ревью третьей стороной.
Криптографически стойкие случайные числа
Используйте источник случайноси предоставляемый ОС. В PHP, например, mcrypt_create_iv($count, MCRYPT_DEV_URANDOM) или напрямую читайте из /dev/urandom.
Всегда проверяйте, что из источника получено нужное количество байт. Если это не так, не пытайтесь исправить такую ошибку самостоятельно при помощи самодельных алгортимов псевдослучайности.