шифрование данных mysql

[dmsoh]

а что если закрыть php фаил с ключами ионкубом? про зенд не говорю так как его можно дезендить, хотя и это сложновато бывает...

а разве ioncube не вскрывают?

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

 

[PHP_Master]

Всё вскрывают.

 

[dmsoh]

Всё вскрывают.

Да, тут не спасет, ни зенд ни ионкуб,
всегда можно константы прочесть или выполнить функцию:

<?php

include("config.php");
print_r(get_defined_constants());

include("crypt.class.php");
print_r(get_declared_classes());

?>

Ну делает же народ как-то проверку файлов лицензий и т.д.
Может есть другие варианты?
В принципе программу содержащую дешифрирование не обязательно на пхп писать, на c++ например.

 

[PHP_Master]

Для особо непонятливых повторяю - программу можно писать хоть на наречии жителей 5 кратера справа на западной стороне Марса.
Если проект написан на PHP, то данные ему надо скармливать в понятном для PHP виде (читай "открыто"). При взломе сервера, перехватывать эти данные - как два байта об асфальт.

зы чтоб прочитать константы, их надо сначала определить

 

[lift]

2dmsoh

PHP_Master правильно сказал, главное не алгоритмы а ключи. А в такой ситуации надо не скрипты и базы с защищать а имено их.
Например заливаеш на один сервак скрипт и базы а на другой заливаеш ключи и делаеш ограничение по IP для доступа. Для гарантии шифруеш все вызовы к ключам под ионкубом и вообще тут вариантов море, главное чтоб возни с восстановлением было потом дафигища у взломщиков.
Что получится, если в данном случае тебя взломают? У тебя сольют скриты и базу шифрованную, начнут ломиться искать как разшифровать инфу, потратят кучу времени на расшифровку всего файла в скрипте (мы же не будем облегчать работу взломщикам и шифровать будем все ) и когда они в итоге долезут до вызова ключа пройдет куча времени. Ты за это время найдеш дырку, исправиш ее, измениш пути вызова (и файлы вызова соответственно) для ключа ну и как положенно смениш само расположение файла ключей. И в итоге взломщики не смогут никаким образом получить файл ключей. Даже если например тебя сломают через соседей, ты никак не сможеш повлиять на это и они после расшифровки залезут к тебе снова чтоб с твоего IP получить файл ключей его уже там не будет. А чтоб узнать где он находиться теперь снова придеться сливать все и все расшифровывать. А за это время... Ну ты понял

 

[valentinus-gvr]

Оптимально это - прийдется держать ключ где то в глубинке пхп исходников если нужна скорость обработки.

А лучше это алгоритм шфрование.. которы проходит через несколько функций пока ключ будет готов.

Как вариант для каждой позиции в мускуле можно создавать свой ключ.

 

[dmsoh]

Спасибо всем за ответы.

Покритикуйте такую схему:

есть 3 сервера.

1 сервер - платежной системы.
2 сервер - содержит ключ.
3 сервер - шифрованную базу и алгоритм дешифрирования, использующий ключ.

сервер платежной системы (1), после оплаты передает информацию на (2) сервер, который проверяет цифровую подпись от севера 1 и вызывает скрипт на сервере (3), посредством, например

file_get_contens('http://server3.net/decrypt.php?id=14&key=hdyshdk63hsldksgdls84jsl');

 

[lift]

dmsoh
1 и 3 сервер можно объединять. Для такого разделения нет объективной предпосылки (исходя из всего что ты написал по крайней мере)
Кстати, возникла мысль по ходу дела: если у тебя именно сервер (реальны или виртуальный - без разници) а не хостинг, то можно сделать кеширование ключа в памяти на какое то время. Для ускорения работы системы. На безопасность это не повлияет практически так как при рипе файлов память текущую никто не дампанет ибо смысла нет в этом.