Шифрование данных в MySQL по ключу пользователя

[mygloo]

Всем привет!
Недавно, столкнулся с такой задачей...
Пользователь небольшого приложения (php+mysql) проявил утопительное желание к шифрованию данных, записываемых в БД.
Есть некоторые идеи.
Собственно, самая вычурная=)))))
(ВСЕ необходимые данные зашифрованы в mysql базе AES шифрованием ПО ключу пользователя)
Ключ системы (сайта): 32 символа. (условно) файл типа "F568HJ7W5KL4FGX92X4NG.keysys'
Ключ пользователя: 32 символа. (условно) файл типа "F85AQ9U521QH10185DGY.keyuser'
Ключ пользователя расположен за дерикторией www =)
Поля таблицы БД зашифрованы AES. тип поля tinyblob
Ключ системы ТОЛЬКО один. Находится на стороннем сервере, известному только разработчику.
При успешной авторизации пользователя, с помощью ключа Системы расшифровывается поле "путь к файлу ключа пользователя".
По этому пути считывается Ключ пользователя.
К ключу пользователя исходным кодом добавляется "соль" из N-ного количества символов и шифруется в base64.
Получившаяся комбинация сохраняется в сессию.
======
По необходимости, переменная ИЗ сессии с комбинацией(шифрованной) проходит через заранее определенную функцию(php):и через "соль" и base64 декодируется в ключ пользователя.
На выходе получаем ключ, для расшифровки tinyblob поля, зашифрованного AES по тому же ключу.

UPDATE: В итоге, ключ пользователя считывается только один раз (за период авторизации) и сохраняется в сессию + привязка к IP пользователя. По необходимости, через функцию вычесляется оригинал ключа и по нему идет запрос SELECT AES_ENCRYPT(`name`,$key_user) AS `name` FROM ...
Попади база к злоумышленнику - врятли что они там найдут...

======

[SkinnyJack]

Хитро!
Можно кодировать/декодировать прямо в браузере, что, по идее, должно защитить от перехвата, уменьшить нагрузку на сервер и упростить добавление новых пользователей. Из минусов такого подхода - отдельный пароль на данные, в случае потери которого теряются все данные.
https://code.google.com/p/crypto-js/#AES

[unimix]

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

[SkinnyJack]

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

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

[unimix]

В любом случае, если кто-то заимел доступ к веб-серверу - это провал.

Если серьёзно подходить к информационной безопасности, то вопрос хранения шифрованных данных на стороннем сервере вполне решаем. Другое дело, что на это денег не хотят тратить. Как, впрочем, и на ТЗ.

Вот, например, пара ссылок по теме:
http://css.csail.mit.edu/cryptdb/
http://css.csail.mit.edu/mylar/