Как защитить ключ шифрования в php?

Question

[afih]

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

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

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

Answer 1

[Сергей Савостин]

Делайте тоже самое - храните ключ в памяти.
В memcahed или в shared memory.
Можете в $ENV хранить (например создавать конфиг php-fpm с установленным $ENV динамически перед запуском и удалять его после запуска).
Только надо подумать об автоматическом рестарте, мало ли...

Comments

[Сергей Савостин]

OnYourLips: брекпоинт в работающий php-демон? Этот кто-то, он root по ssh получил что ли?

Answer 2

[xmoonlight]

Пишется демон (db-wrapper) на сокет, который получает ключ из файла (или другого хоста) для дешифрования результата БД внутри этого процесса-демона. Соль ключа - хранится внутри этого процесса с привязкой к домену или MAC-интерфейса.
Демон запускается от имени другого пользователя с урезанными правами, нежели чем web-сервер и PHP.

Можно дешифровать данные непосредственно на клиенте через JS.
Но, это уже совсем другая история....

Comments

[SagePtr]

Если сервер скомпрометируют, то и клиентские скрипты подменят, так что в таком случае автора ничего не спасёт)

[xmoonlight]

SagePtr: подмена скриптов сразу повлечет за собой визуальную не читаемость данных на экране, что не может остаться незамеченным))
т.е. сам ключ хранимый в локальном хранилище браузера привязан к сессии - он не передается никогда по сети.
Хотя, может еще прилететь НЛО и все раскодировать!)))

[SagePtr]

xmoonlight: причём тут нечитаемость? В скрипт может быть добавлена закладка, не заметная пользователю

[xmoonlight]

SagePtr: при чем тут закладка?

Answer 3

[SagePtr]

На сервере ключ уворуют или внедрят код, который уворует.
На клиенте если просчитывать - тоже подменят скрипты и смогут уворовать.
Вижу пока что только один вариант - если в качестве клиента будет использоваться программа, подписанная ЭЦП автора, которая не будет полностью доверять серверу. А при скачивании обновлений проверять их ЭЦП и только тогда ставить. В итоге даже если сервер взломают, то не получат ключ, которым автор подписывает программу, и не подменят её, а ключи пользователей дальше клиента никуда не уйдут. Хотя и тут могут подменить инсталлятор программы, но получат его только новые пользователи.