Зашифровать БД форума

[antiadmin]

Бред. Зашифровать можно максимум в base64, что глупо, важные данные (пароли) и так зашифрованы в md5

 

[q2dm1]

база данных на отдельном сервере, т.е. вместо localhost другой ip

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

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

это не 100% гарантия защиты, но проблему упрощает

 

[zerdek]

Бред. Зашифровать можно максимум в base64, что глупо, важные данные (пароли) и так зашифрованы в md5

не нужно искажать понятия.
base64 - это обычная стандартная кодировка, а не "зашифрофка".
md5 - это хеш, а не шифр.
даже не удобно говорить об этом...

по теме: уже обсуждалось, если по уму: то шифрованная БД на одном сервере, на нем же и простой итнерфейс доступа к БД(в виде скриптов), на втором сервере уже производиться работа с данными - шифровка/расшифровка, не не напрямую с БД, а через интерфейс на первом сервере.

хакнут(или физический доступ) к первому серверу - все данные в БД зашифрованы, а ключ находится на втором сервере.

хакнут(или физический доступ) ко второму серверу - тут должен уже отработать интерфейс доступа к БД на первом сервере, который не позволяет тупо сливать все данные или делать выборки select * from table. т.е. он отдает только ограниченные данные и только по "честным" запросам. если частота запросов увеличивается или еще какие-то аномалии, то или алерт админу или блок всего.

 

[koss4u]

Если до твоей базы дборались, то и до ключа шифровки тоже, т.е. пить Боржоми уже поздно.

 

[tostrss]

Если есть физический доступ к серверу, то базу скачуют в ЛЮБОМ случае, хоть ерез правку исходников, хоть ПРОСТО СЛИВ ФАЙЛЫ БАЗЫ (подняв рута).
Так то схема 2 серверов, работать не будет. Получая доступ к одному из них, базу можно слить всегда.

тут должен уже отработать интерфейс доступа к БД на первом сервере, который не позволяет тупо сливать все данные или делать выборки select * from table. т.е. он отдает только ограниченные данные и только по "честным" запросам.

нету такого
Можно поивзращатся через tcpdump.

Если до твоей базы дборались, то и до ключа шифровки тоже, т.е. пить Боржоми уже поздно.

Неверно, большинство взломов, идет через sql инъекцию, так вот, если БД зашифровано и нет прав на чтение файлов, хакер ничего не сможет сделать ,т.к. запросы к бд он может делать, а файлы для расшифровки данных он не сможет прочесть

 

[balcon]

Сталкивались с такими заказами. Мы решили это так: на этапе записи или изменения в таблице (операции INSERT или UPDATE) шифровали данные средствами PHP. При выборке (точнее даже при публикации пользователю) расшифровывали средствами PHP.
Но стоит отметить, что там система была совершенно иной сложности и требований к хранению информации! Вообще любое шифрование – это результат выполнения над данными последовательности арифметических операций – поэтому логично задать вопрос: целесообразно ли увеличивать время отклика системы для пользователя?

 

[zerdek]

Если есть физический доступ к серверу, то базу скачуют в ЛЮБОМ случае, хоть ерез правку исходников, хоть ПРОСТО СЛИВ ФАЙЛЫ БАЗЫ (подняв рута).

ну и? сольют зашифрованную базу данных. типа:

insert into table (id,login, pass, realname) VALUES(1,'hsHGG676554eJHJG','iyFDe7t6t6t3','jkhuihHGUUI7868guigh7')

ну посмотрят на структуру таблиц, ежели оно им надо, ну посмотрят на абракадабру, но расшифровать данные не смогут.

Добавлено через 11 минут[/size]

Но стоит отметить, что там система была совершенно иной сложности и требований к хранению информации! Вообще любое шифрование – это результат выполнения над данными последовательности арифметических операций – поэтому логично задать вопрос: целесообразно ли увеличивать время отклика системы для пользователя?

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

 

[tostrss]

insert into table (id,login, pass, realname) VALUES(1,'hsHGG676554eJHJG','iyFDe7t6t6t3','jkhuihHGUUI7868guigh7')

ну посмотрят на структуру таблиц, ежели оно им надо, ну посмотрят на абракадабру, но расшифровать данные не смогут.

Ды аж пипец не смогут. У тебя движок логин отображает такой абракодаброй? Я думаю что, движок сможет расшифровать эти записи и покажет тебе в нормальном виде. А если в движке ЕСТЬ декодер данных из базы, то базу всегда можно получить в нормальном виде. Как бы ты ее не зашифровал, на выходе все равно получается чистый текст и этот выход всегда можно отследить.

в общем случае ты не увидишь ничего. т.к. там скорее всего будет ssh-тунель. кстати, очень удобная и неприхотливая вещь, как раз через него я и работаю с базами у себя.

Тоже глупости. Какая разница как идет коннект с базой? Я же написал, имея доступ к серверу, можно слить ВСЮ базу в чистом виде, при условии что она декодируется на этом серве.

ssh-тунель

Очень тормозная вещь.

 

[zerdek]

Ды аж пипец не смогут. У тебя движок логин отображает такой абракодаброй? Я думаю что, движок сможет расшифровать эти записи и покажет тебе в нормальном виде. А если в движке ЕСТЬ декодер данных из базы, то базу всегда можно получить в нормальном виде. Как бы ты ее не зашифровал, на выходе все равно получается чистый текст и этот выход всегда можно отследить.

перечитайте внимательно мой первый Для просмотра ссылки Войди или Зарегистрируйся.
база на одном сервере, движок и декод - на другом.
движок НЕ может сделать прямой sql запрос к базе.

Тоже глупости. Какая разница как идет коннект с базой? Я же написал, имея доступ к серверу, можно слить ВСЮ базу в чистом виде, при условии что она декодируется на этом серве.

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

ssh-тунель
Очень тормозная вещь.

[OFFTOPIC]не любите котят? да вы просто не умеете их готовить! (с) не мое[/OFFTOPIC]
вот чего-чего - так тормознутости за ssh-тунелем я точно не замечал. работаю уже далеко не первый год, иногда и на довольно убитых каналах.
и как раз на убитых каналах тунель и выручает.

Добавлено через 31 минуту

если в движке ЕСТЬ декодер данных из базы, то базу всегда можно получить в нормальном виде

не всю базу, а только какое-то кол-во данных, т.к. sql - не доступен. тут еще играет роль и фактор времени.
если данные действительно ценные, то и за сервером будет надлежащий надзор и всякие аномалии вылезут очень быстро. из простого - на автомате проверка кода движка от изменений(даже в вордпресе это есть в виде плагина), проверка запущенных процессов по крону, парсинг логов, проверка открытых соединений и т.д.
да и код самого движка можно хоть в зенд, хоть в куб завернуть, чтобы понадобилось время на его вскрытие и чтобы не так просто было понять и модифицировать код.

 

[tostrss]

Вероятность что взломают сервер с БД - 0.1%. Т.к. ее адресс и данные никому не известны.
Вероятность что взломают именно сервер с движком - 99.9%.

А если взломают сервер с движком, то пофигу где расположена база, на этом серве или на другом. ПОФИГУ.
Можно будет вытащить любые данные, при любой шифровке. Даже если у тебя там стоят куча ограничений, трижды шифрованные данные, закодированные скрипты и т.д.

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

А ты попробуй выдержать 200 юзеров онлайн на любом движке, почувствуешь разницу между локальным коннектом, удаленный коннектом и ssh-тунелем.