Сведения о вопросе

DED

09:31, 11th August, 2020

Теги

Java   +2   ещё    

Хранение криптованных данных в БД, (де)криптование на клиенте

Просмотров: 312   Ответов: 4

Есть данные, которые хранятся в MySQL и html-страница, в которой происходит просмотр и редактирование данных посредством JS+AJAX. Нужно реорганизовать схему таким образом, чтобы данные хранимые в БД были «нечитаемы», а«читаемы» были только по ключу на «клиенте». Желательно не отходить от MySQL/PHP на сервере и JS+AJAX на клиенте.

Интересует направление в котором рыть: идеология, технологии…
Спасибо.



  Сведения об ответе

ITSME

08:03, 10th August, 2020

Вообще вы по-моему изобретаете какой-то велосипед.
«данные будут читаться по ключу на js» какой в этом смысл? делаете стандартную авторизацию пользователей. Далее на уровне пхп в зависимости от уровня доступа выбираете нужные данные.

Для реализации же вашей схему будет как-то так:
Выбираете любой алгоритм, две функции из которого (encode,decode) можно будет реализовать на пхп и js. Далее перед вставкой данные кодируете, а при запросе раскодируете.

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

Например Функцию раскодирования можно написать прямо в mysql (если у вас свой сервер или есть доступ к хранимым процедурам).
Тогда выборка будет вида select decode(text,key) from table…
key можно передавать при GET/POST запросе, но в таком случае клиенту полетят уже расшифрованные данные. Если боитесь перехвата, опять-таки есть https.

Если уж очень хочется расшифровывать на js ajax вам в помощь.
Берете любой фреймворк, например jQuery, там есть функция $.ajax
Код будет выглядеть как-то так (пишу с головы могут быть ошибки):
<script>
function my_decode(data,key)
{
//Тут будет алгоритм декодирования
}
function LoadData()
{
$.ajax({
  url: 'ajax.php?OrderNo=5',
  success: function(data) {
    $('.result').html(my_decode(data,key));
  }
});
}
</script>
<a href="javascript: void(0);" onclick="LoadData()">Показать данные</a>
<div id="result">Сюда выведутся данные</div>

Вот что произойдет. По нажатию на ссылку произойдет ajax запрос, который вызовет скрипт, который сделает выборку данных из базы. Затем после успешного вызова данные расшифруются на стороне клиента и в загрузятся расшифрованные данные.
Дело за выбором алгоритма шифрования


  Сведения об ответе

nYU

18:33, 21st August, 2020

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


  Сведения об ответе

DINO

10:37, 19th August, 2020

Еще вот какая мысль. В открытом виде должны существовать ключи (чтобы не усложнять работу мускула) и поля по которым используются условия выборок. Но тут возникает проблема. По некоторым полям система делает autocomplete (в процессе написания текста в поле аяксом подтягиваются совпадения из базы). От этого нужно будет отказываться либо использовать алгоритм который криптует «символ в символ». Но, вероятно, такие алгоритмы не слишком безопасны.


  Сведения об ответе

darknet

19:57, 24th August, 2020

Делаю так (проверяю концепцию пока только):
ключи, поля для поиска/фильтров хранятся в виде md5-хэша плюс одно поле, в котором хранится зашифрованный сериализованный объект (включая те поля, конечно, которые захэшированы) — для условий = != в WHERE или JOIN работает нормально

Столкнулся с проблемами при работе с упорядоченными значениями:
-поиск по > < BEETWEEN и т. п.,
-сортировка
-и тоже автокомплит (по сути LIKE)

Все проблемы связаны с тем, что любое, имхо, сколь-нибудь стойкой шифрование/хэширование не должно сохранять порядка. Пока решил таким костылём: дополнительно для упорядоченных полей ввёл числовое поле %property_name%_order, для условий типа expired<today ищу сначала expired_order для expired_hash==md5(today), потом выбираю всё что меньше. Сразу вылез недостаток подхода — работа возможна только для множеств без пропусков (вернее для множеств, где существуют граничные значения поиска), как обойти его на стороне сервера (чтобы клиент делал только один запрос на поиск) ещё не придумал. Ну, и вставка/перемещение довольно долгая процедура — обновляется большая часть таблицы


Ответить на вопрос

Чтобы ответить на вопрос вам нужно войти в систему или зарегистрироваться