В одном из тестовых заданий по php есть такое требование по реализации функционала: "Информация должна безопасно храниться в SQL. Злоумышленники не должны видеть электронные адреса и телефоны пользователей, даже если они взломают сайт и получат полный доступ к базе данных и всем файлам". Насколько это реализуемо? Разумеется, в БД вносятся зашифрованные обратимым шифрованием данные, например, с помощью openssl_encrypt($data , $method, $key). Но значения параметров этой функции ведь прописаны в скриптах, и скрипты деть некуда, максимум, вынести выше корня сайта? Прошу совета, существуют ли техники сокрытия данных кроме шифрования и выноса исполняемых PHP-файлов выше корня сайта?
Довольно странное требование. Обычно только пароли не хранят открыто. А емейлы и телефоны хранятся как есть. Первый это часто логин. Даже если пытаться это шифровать/расшифровывать то видимо как то мудрено надо, ключ локально не сохранишь, раз к скрипту у них доступ есть
истину --- Добавлено --- @118_64, перед тем как беспокоиться об данных, нужно сначала обеспокоиться об качестве написания скриптов и содержании их сервером --- Добавлено --- так что тестовое задание тупо теоремой можно закончить. --- Добавлено --- почти все платные хосты, предоставляют доступ "выше корня"
Система безопасности хороша настолько, насколько хорошо её самое слабое звено. Если каким-то образом злоумышленник может добраться до твоих скриптов на хостинге, то он получит всё. Ну а в целом, ты верно рассуждаешь. Добавлю что ключи не должны храниться с исходниками вместе. Например в Laravel принято файл .env с приватными штуками НЕ добавлять в git. Количество людей, имеющих доступ к файлам, должно быть ограничено. Программисты в общем случае такого доступа не имеют и работают только со своими ключами для девелоперской версии БД. --- Добавлено --- Доступ к файловой системе есть только у админа (девопса) и того, кто может его заменить на случай ахтунга.
Спасибо. Т.е. требование сделать данные в БД заведомо защищенными при доступе злоумышленника к скриптам на сервере очевидно нереализуемо.
Мыло/телефон может шифроваться открытым паролем и храниться в расшифрованном виде в сессии. --- Добавлено --- Хотя если под всеми файлами имеются в виду в том числе и файлы сессий, тогда это не вариант. --- Добавлено --- Можно на клиенте хранить --- Добавлено --- Как пить дать, тест для примитивных созданий, а мы тут рассуждаем, глядя с нашей колокольни.
miketomlin, Sail, спасибо. Тогда генерировать $key, записывать в куку, и использовать уже его для decrypt/encrypt при обращении к серверу в дальнейшем?
Я по открытому паролю предложил шифровать/дешифровывать. --- Добавлено --- Если вы потеряете ключ, как будете дешифровывать? Тогда только ключ, зависящий от пароля.
Где об этом можно прочитать? Гугл ничего внятного не выдал по "open password encrypt". Вижу возможность использовать собственный пароль как соль/параметр шифрования. Но вы, скорее всего, имеете в виду что-то другое.
У меня знакомый джавист делал, что ключи для расшифровки при старте приложения надо было руками загрузить через браузер, поэтому на сервере их вообще не было. То есть если не взломал комп админа, ключи не получишь. Другое дело, рестарт системы автоматически невозможен. Традиционный php так не умеет, но, теоретически, такое можно реализовать на каком-нибудь ReactPHP или Swoole.
Если пользователь у сайта один, то не вижу причин почему всё(ключи, логины, пароли, хост базы...) не хранить в кукиз. Для параноиков еще посоветую перед каждой сессией загружаться по ftp например и сверять хэш скриптов на предмет их правок.
@Drunkenmunky А причём тут один пользователь? Суть приёма не в том. Вся база, все данные пользователей зашифрованы. Ключи для расшифровки хранятся у админа, в исходном коде их нету, на сервере их нету. После того, как исполняемый файл (в случае джавы - jar-файл) запущен, админ переходит в браузере на специальную страничку, где загружает в систему ключи шифрования (которые система хранит в оперативной памяти), и только после этого любой пользователь может зайти и пользоваться сайтом, потому что система знает, как расшифровать базу. Но, чтоб приём работал, нужно где-то хранить ключи, где теоретически их очень трудно найти. Кстати, в традиционном php можно для этих целей попробовать редиску, хотя, получив доступ к серверу, из редиски достать легче, чем из области оперативной памяти, отведённой программе. Но для этого программа должна висеть в памяти всё время, а не выгружаться/загружаться каждый запрос, как это происходит обычно у нас.