Насправді немає вбудованих функцій MySQL для обробки складних зашифрованих налаштувань ключів. Вам потрібно буде реалізувати основну частину логіки шифрування у власному PHP та / або коді на стороні браузера (javascript?).
Але ваші висловлені занепокоєння є дещо своєрідними: здається, що вашими єдиними реальними проблемами є напад SQL або груба сила (гадаю пароля, я припускаю) з віддаленого робочого місця робочого столу клієнта / ноутбука. Це змушує мене підозрювати, що у вас вже заплановані інші, не згадані заходи безпеки, і ви проаналізували можливі шляхи компромісу.
Для одного, я припускаю, що у вас є правила брандмауера, що захищають хост MySQL / PHP від будь-якого доступу з неприйнятих IP-адрес віддаленого клієнта. Якщо я маю рацію, то є сенс, що ви турбуєтесь лише про атаки з боку робочих станцій, що скомпрометовані.
Крім того, я припускаю, що ви розумієте, що якщо зловмисник на віддаленому хості клієнта може перейти на root / Admin privs або безпосередньо поставити під загрозу власний обліковий запис реального користувача, то ці дані клієнта мають нульовий захист незалежно від шифрування чи будь-яких інших гарантій. (Зловмисник може прочитати ключі з будь-якого місця, де вони збережені на диску, або прослухати їх, коли реальний користувач вводить їх під час входу, а ключі ведуть до даних.)
Починаючи з цих двох припущень, для нас є сенс зробити висновок, що єдиними двома відповідними загрозами є: A) відгадка пароля від грубої сили та B) спроби введення SQL:
- Якщо зловмисник не отримає ключ реального користувача, або якщо він хоче отримати доступ до більше ніж просто реальних даних користувача, він може спробувати брутально-примусові кредити для входу для реального користувача або іншого облікового запису. (Теоретично ви можете заблокувати кожен обліковий запис до певного віддаленого клієнта IP, що також допоможе поділити ризики.)
- Якщо зловмисник дійсно отримає дійсний ключ для реального користувача, він має проспект повз екран входу (який, мабуть, досить простий, щоб бути захищеним), до м'якого нижнього шару потенційно помилкового коду програми. Успішне введення SQL з контексту реального користувача може також дати йому доступ до даних інших клієнтів.
Тепер поговоримо про те, як шифрування на стороні сервера застосовується до цих ситуацій:
- Шифрування на стороні сервера безумовно допомагає проти загрози введення SQL. Якщо значення рядків зашифровані в таблицях БД, зловмисник може бачити лише хибний шифротекст даних, що належать до інших облікових записів. Загроза стримана, розділена.
- Однак жорстоке примушування пароля, насправді, не стає складніше для зловмисника, який стикається з шифруванням на стороні сервера. Незалежно від того, чи зберігаються ключі користувачів на сервері чи генеруються на місці з пароля, єдине, що має значення, - чи маєте ви правильний пароль. Або сервер вирішить дозволити вам використовувати дійсний збережений ключ, оскільки він перевіряє правильність вашого пароля, або він обчислює дійсний для вас ключ, оскільки ваш пароль є правильним входом для створення цього ключа.
З іншого боку, шифрування на стороні клієнта насправді робить атаки паролів грубою силою неактуальними. Ви не можете жорстоко примусити правильно сконструйований ключ. Клієнтське шифрування зберігає в основному той самий рівень захисту від введення SQL, як і шифрування на стороні сервера. Клієнт може передати ключ до сервера під час входу, зберігаючи копію в пам’яті до завершення сеансу, що спричиняє навантаження на процесор криптовалюти на сервер. Або клієнт може обробляти шифрування / дешифрування самостійно, у браузері. Існують злети і падіння обох методик:
- Передати свій ключ на сервер куди простіше кодувати та керувати, і, як правило, набагато швидше за рахунок більш оптимізованого криптокоду (компільований C, мабуть).
- Чистий підхід до клієнта надає додаткову безпеку, оскільки навіть якщо зловмисник отримує корінь на сервері, він все ще не може прочитати зашифровані дані, і він ніколи не зможе їх прочитати. Єдиний можливий вектор атаки - це компрометувати робочу станцію віддаленого клієнта.
Нарешті, зазначу, що в шифруванні даних у базі даних є величезні операційні недоліки. Оскільки представлення зашифрованих даних по суті є випадковими шаблонами, основні функції бази даних, такі як індексація, з'єднання тощо, не працюватимуть. Клієнт бере на себе величезне логічне навантаження і може втратити багато переваг, які зазвичай приносять функції бази даних.