- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Доброго времени.
В БД одного проекта помимо контента есть данные, которые надо как-то защитить от возможного несанкционированного доступа.
Спросил своего программиста, что можно сделать, он предложил зашифровать на основе слова-ключа в скрипте, который будет расшифровывать и выдавать инфу пользователю (не знаю как правильно данный вид шифровки называется)
Как я понял, в случаи доступа именно к самой БД такой вариант достаточно надёжен, но меня интересует момент с заливкой шеллов. Шелл может узнать слово-ключ и, следовательно, расшифровать данные?
Движок написан на php+mysqli, известных дыр вроде нет
Обычно в таких случаях ключ расшифровки не хранят вообще а вводят руками при старте системы, он хранится в памяти только.
Вы на случай физической кражи БД защититься хотите?
Обычно в таких случаях ключ расшифровки не хранят вообще а вводят руками при старте системы, он хранится в памяти только.
Вы на случай физической кражи БД защититься хотите?
Вот тут вас немножко не понял, при старте системы? о какой системе речь? речь идёт о веб-сайте, располагающемся у какого-либо хостинг оператора.
Смотрите, ситуация такая: есть сайт, на него админ/менеджер через админку заносит определённые данные, которые юзер может получить у себя в личном кабинете на этом же сайте.
Задача максимально усложнить возможность неправомерного доступа к этой инфе третьим лицам (хостинг-оператор не в счёт, понятное дело, что у них вообще прямой доступ ко всем файлам, расположенным на их серверах)
Т.е. мне предложили что-то вроде такого (как я понял): при добавлении данных производить шифрование и заносить в БД уже в зашифрованном виде, а при выдаче вытягивать и расшифровывать.
Физической кражи? если вы про hdd, на котором БД, то нет))) всё через сеть Интернет
Green arrow, Данные гоните в sha-512 в бд, а пароль доступа храните в файле который прошёл обфускацию и накрыт коммерческим средством защиты, например Ioncube.
Проясню момент по поводу обфускации- она должна быть сделана только вручную, иначе код будет виден посторонним.
Возможно скрипткиддисов это отпугнет, кто шарит обязательно найдет ваш пароль/алгоритм, в ваших же скриптах. Ioncube и прочие с успехом ломаются. Сольют все данные, а потом произведут отладку.
Не занимайтесь всякой ерундой, повышайте лучше безопасность своей системы.
Мануалов в сети полно.
Т.е. мне предложили что-то вроде такого (как я понял): при добавлении данных производить шифрование и заносить в БД уже в зашифрованном виде, а при выдаче вытягивать и расшифровывать.
А как будет работать поиск по БД? :)
Green arrow, Данные гоните в sha-512 в бд,
sha-512 есть алгоритм хэширования,
то есть расшифровать не получится.
при добавлении данных производить шифрование и заносить в БД уже в зашифрованном виде, а при выдаче вытягивать и расшифровывать.
Т.е. при занесении нужен ключ и при выводе...
Действительно ли оправдан такой гемморой?
Опять же - ключ шифрования должен где-то храниться. И это "где-то" - хостинг. А значит получив доступ к хостингу хакер может всё расшифровать.
;13343036']А как будет работать поиск по БД? :)
ну там как бы поля в бд привязаны к ИД или как-то так
Green arrow, Данные гоните в sha-512 в бд, а пароль доступа храните в файле который прошёл обфускацию и накрыт коммерческим средством защиты, например Ioncube.
Проясню момент по поводу обфускации- она должна быть сделана только вручную, иначе код будет виден посторонним.
омг шифруем зашифрованное, чтобы зашифровать шифр )) благодарю за совет)
Т.е. при занесении нужен ключ и при выводе...
Действительно ли оправдан такой гемморой?
Опять же - ключ шифрования должен где-то храниться. И это "где-то" - хостинг. А значит получив доступ к хостингу хакер может всё расшифровать.
Да и на вход и на выход нужен будет ключ
Так вот специально для этого и открыл топик, чтобы попытаться понять оправдано ли всё это и имеет ли смысл)
чтобы попытаться понять оправдано ли всё это и имеет ли смысл)
Однозначно никто не скажет - оправдано ли.
Нужно самому соотнести оценить важность данных с проблемами при реализации этой защиты (нагрузки при (рас)шифровках, риски получения ключей др способами и тд) и собсно мероприятиями по защите.
Лично я во многом согласен с vladimir_112. Но мб ценность данных не такая, как кажется.
По топику: шифровать не имеет смысла, кто хочет тот найдет.
Для разминки ума, возможны варианты:
1. Как предлагали выше, шифрование на уровне приложения.
2. Шифрование используя функции mysql напрямую из приложения.
3. Шифрование используя свои хранимые функции.
4. Свои хранимые функции сделать бинарником (UDF) в него же можно засунуть и ключ шифрования. (для этого варианта нужна вдска или сервер)