Задать вопрос

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

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

Интересует направление в котором рыть: идеология, технологии…
Спасибо.
  • Вопрос задан
  • 2642 просмотра
Подписаться 5 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 4
@Ajex
Вообще вы по-моему изобретаете какой-то велосипед.
«данные будут читаться по ключу на 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 запрос, который вызовет скрипт, который сделает выборку данных из базы. Затем после успешного вызова данные расшифруются на стороне клиента и в загрузятся расшифрованные данные.
Дело за выбором алгоритма шифрования
Ответ написан
FeNUMe
@FeNUMe
не понимаю в чем сложность. выбираете криптостойкий алгоритм шифрования(в идеале уже реализованый в js), перед отправкой данных — шифруете этим алгоритмом с пользовательским ключем. так в базе будет лежать с виду мусор… ну и обратное действие — аяксом запрос инфы с сервера, дешифровка введенным ключем, вывод на странице. Но думаю если шифровать каждое поле данных отдельно — будет слишком медленно, лучше хранить все блоками данные которые выводятся вместе.
Ответ написан
flom
@flom Автор вопроса
Еще вот какая мысль. В открытом виде должны существовать ключи (чтобы не усложнять работу мускула) и поля по которым используются условия выборок. Но тут возникает проблема. По некоторым полям система делает autocomplete (в процессе написания текста в поле аяксом подтягиваются совпадения из базы). От этого нужно будет отказываться либо использовать алгоритм который криптует «символ в символ». Но, вероятно, такие алгоритмы не слишком безопасны.
Ответ написан
Комментировать
Делаю так (проверяю концепцию пока только):
ключи, поля для поиска/фильтров хранятся в виде md5-хэша плюс одно поле, в котором хранится зашифрованный сериализованный объект (включая те поля, конечно, которые захэшированы) — для условий = != в WHERE или JOIN работает нормально

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

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

Войдите, чтобы написать ответ

Похожие вопросы