Зашифрованный запрос к базе данных

StackOverflow https://stackoverflow.com/questions/181130

Вопрос

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

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

Если быть кратким, то окружающая среда выглядит примерно так:

  • Приложение, в котором внешний интерфейс используется для доступа к ключам шифрования/дешифрования, а серверная часть используется только для хранения и запросов.

  • Имея базу данных, к которой у вас нет доступа к нескольким полям, например, скажем, «адрес», который, как обычно, представляет собой текст/varchar.

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

Основная проблема примерно такая: как последовательно делать запросы к базе данных, невозможно делать такие вещи, как «где адрес типа '%F§YU/´~#JKSks23%'».(ЕСЛИ у кого-то есть ответ на этот вопрос, не стесняйтесь стрелять).

Но можно ли это сделать? where address='±!NNsj3~^º-:'?Или это также полностью съест базу данных?

Еще одним ограничением, которое может возникнуть, является то, что передняя часть не имеет достаточной вычислительной мощности, поэтому уже шифрование/дешифрование информации начинает доводить ее до предела.(Говорю это только для того, чтобы избежать ответов типа «Экспорт объединения таблиц во внешний интерфейс и выполнение запроса там».)

Может ли кто-нибудь указать мне направление, в котором следует продолжать думать об этом?

Что ж, спасибо за столь быстрые ответы в 4 часа утра, впервые использую это сообщество. Я действительно впечатлен этим сообществом.(Или, может быть, это просто другой часовой пояс)

Просто снабжаю некоторой информацией:

Основная проблема заключается в частичном совпадении.В большинстве баз данных обязательным требованием является разрешение частичных совпадений.Основное ограничение на самом деле владельцу базы данных не будет разрешено заглядывать в базу данных в поисках информации..За последние 10 минут я придумал возможное решение, которое снова распространяется на возможные проблемы с базой данных, к которым я добавлю здесь:

Возможное решение, позволяющее получастичное сопоставление:

  • Пароль + пара публичных полей пользователя на самом деле являются ключом для шифрования.Идея аутентификации состоит в том, чтобы зашифровать статическое значение и сравнить его с базой данных.
  • Создание нового набора таблиц, в которых информация хранится в анализируемом виде, что означает что-то вроде:«4-я улица» станет двумя зашифрованными строками (одна для «4-й», другая для «Улицы»).Это уже позволило бы получастичное сопоставление, поскольку поиск уже можно было выполнять в отдельных таблицах.

Новый вопрос:

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

Пост скриптум:Я отклонил ответ Кейда Ру только для того, чтобы обеспечить дальнейшее обсуждение и, в частности, возможный ответ на новый вопрос.

Это было полезно?

Решение

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

В более типичном приложении, в конечном счете, ключи будут доступны кому-то в цепочке — возможно, веб-серверу.

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

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

Другие советы

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

[я не совсем понимаю контекст/ограничения, которые требуют такого уровня паранойи]

РЕДАКТИРОВАТЬ:"правовые ограничения", да?Надеюсь, вы не замешаны ни в чем противозаконном, мне не хотелось бы быть непреднамеренным соучастником...;-)

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

Несколько месяцев назад столкнулся с той же проблемой:вся база данных (кроме индексов) зашифрована, и возникла проблема с частичными совпадениями.

Я искал в Интернете решение, но, похоже, с этим особо нечего поделать, кроме «обходного пути».

Решение, которое я наконец принял:

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

  2. Выполните частичное сопоставление с этой временной таблицей и получите идентификаторы.

  3. Запросите реальную таблицу для этих идентификаторов и верните результат.

  4. Удалите временную таблицу.

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

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

Вы хотите использовать хеширование md5.По сути, он берет вашу строку и превращает ее в хеш, который невозможно воспроизвести.Затем вы можете использовать его для проверки на предмет позже.Например:

$salt = "123-=asd";
$address = "3412 g ave";

$sql = "INSERT INTO addresses (address) VALUES ('" . md5($salt . $address) . "')";
mysql_query($sql);

Затем, чтобы подтвердить адрес в будущем:

$salt = "123-=asd";
$address = "3412 g ave";

$sql = "SELECT address FROM addresses WHERE address = '" . md5($salt . $address) . "'";
$res = mysql_query($sql);
if (mysql_fetch_row($res))
    // exists
else
    // does not

Теперь он зашифрован на стороне базы данных, поэтому никто не сможет его найти, даже если он заглянет в ваш исходный код.Однако обнаружение соли поможет им расшифровать ее.

http://en.wikipedia.org/wiki/MD5

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

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

Делаете запросы к зашифрованным данным?Если вы используете хороший алгоритм шифрования, я не представляю, как это сделать.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top