Як захистити паролі бази даних в PHP?

Коли програма PHP з'єднує базу даних, звичайно, потрібно пройти логін та пароль. Якщо я використовую єдиний логін для мінімального дозволу для своєї програми, PHP повинен десь знати, що цей логін та пароль. Який найкращий спосіб захистити цей пароль? Здається, що просто записати його в PHP-коді - це не дуже гарна ідея.

Кілька людей неправильно читають це як питання про збереження паролів у базі даних. Це неправильно. Йдеться про те, як зберігати пароль, який дозволяє вам потрапити до бази даних.

Звичайним рішенням є переміщення пароля з вихідного коду у файл конфігурації. Потім залиште адміністрацію та закріпіть цей файл конфігурації до системних адміністраторів. Таким чином розробникам не потрібно нічого знати про виробничі паролі, і немає запису пароля у вашому джерелі управління.

Якщо ви хостите на чужому сервері і не маєте доступу поза вашою веб-коренею, ви завжди можете помістити свій пароль та / або підключення до бази даних у файл, а потім заблокувати файл за допомогою .htaccess:

<files mypasswdfile>
order allow,deny
deny from all
</files>

Найбезпечніший спосіб - взагалі не мати інформації, вказаної у вашому PHP-коді.

Якщо ви використовуєте Apache, це означає, щоб встановити дані про з'єднання у вашому файлі httpd.conf або віртуального файлу хостів. Якщо ви це зробите, ви можете викликати mysql_connect () без параметрів, це означає, що PHP ніколи не виводить вашу інформацію.

Ось як ви вказуєте ці значення в цих файлах:

php_value mysql.default.user      myusername
php_value mysql.default.password  mypassword
php_value mysql.default.host      server

Тоді ви відкриєте своє з'єднання mysql так:

<?php
$db = mysqli_connect();

Або так:

<?php
$db = mysqli_connect(ini_get("mysql.default.user"),
                     ini_get("mysql.default.password"),
                     ini_get("mysql.default.host"));

Збережіть їх у файлі поза веб-коренем.

Для надзвичайно безпечних систем ми шифруємо пароль бази даних у файлі конфігурації (який сам захищений системним адміністратором). Після запуску програми / сервера програма потім запитує системного адміністратора на ключ розшифровки. Потім пароль з бази даних зчитується з конфігураційного файла, розшифровується та зберігається в пам'яті для подальшого використання. Все ще не на 100% захищений, оскільки він зберігається в розшифрованій пам'яті, але вам доведеться викликати це "досить безпечно" в якийсь момент!

Це рішення є загальним, оскільки воно корисне як для відкритих, так і для закритих програм.

1. Створіть користувача ОС для своєї програми. Дивіться http://en.wikipedia.org/wiki/Principle_of_least_privilege
2. Створіть змінну середовища (без сеансу) ОС для цього користувача з паролем
3. Запустіть програму як цього користувача

Переваги:

1. Ви не будете перевіряти ваші паролі в контролі джерела випадково, тому що не можете
2. Ви не випадково викрутите дозволи на файл. Ну, може, але це не вплине на це.
3. Читати може лише користувач root або той користувач. Корінь може будь-коли читати всі ваші файли та ключі шифрування.
4. Якщо ви використовуєте шифрування, як ви надійно зберігаєте ключ?
5. Працює x-платформа
6. Будьте впевнені, щоб не передавати енввар недовіреним процесам дитини

Цей метод запропонований Хероку, які є дуже успішними.

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

mysql_connect("localhost", "me", "mypass");

В іншому випадку найкраще зняти облікові дані після оператора connect, оскільки облікові дані, які не знаходяться в пам'яті, не можуть бути прочитані з пам'яті ;)

include("/outside-webroot/db_settings.php");  
mysql_connect("localhost", $db_user, $db_pass);  
unset ($db_user, $db_pass);  

Ваш вибір є обмеженим, оскільки, як ви кажете, вам потрібен пароль для доступу до бази даних. Один загальний підхід - це зберігання імені користувача та пароля в окремому файлі конфігурації, а не в основному сценарії. Тоді обов’язково зберігайте це за межами основного дерева дерева. Так було, якщо виникає проблема веб-конфігурації, яка залишає ваші файли php просто відображатись як текст, а не виконувати їх, ви не виставляли пароль.

Крім того, ви знаходитесь у правильних рядках із мінімальним доступом до облікового запису, який використовується. Додайте до цього

• Не використовуйте комбінацію імені користувача / пароля ні для чого іншого
• Налаштуйте сервер бази даних так, щоб він приймав з’єднання тільки з веб-хостом для цього користувача (localhost ще краще, якщо БД знаходиться на одній машині). Таким чином, навіть якщо дані відкриті, вони нікому не корисні, якщо вони не мають іншого доступу до машина.
• Заблукайте пароль (навіть ROT13 це зробить), він не загрожує захистом, якщо деякі отримують доступ до файлу, але, принаймні, це запобіжить випадковому перегляду його.

Петро

Якщо ви використовуєте PostgreSQL, він шукає ~/.pgpassпаролі автоматично. Додаткову інформацію див. У посібнику .

Раніше ми зберігали DB / user DB у файлі конфігурації, але з тих пір потрапили в параноїдальний режим - прийнявши політику Defense в глибині .

Якщо ваша програма порушена, користувач матиме доступ до читання до вашого конфігураційного файлу, і тому зломщик може прочитати цю інформацію. Файли конфігурації також можуть потрапляти під контроль версій або копіюватися навколо серверів.

Ми перейшли на збереження користувальницьких / пропускних змін у середовищі змінних, встановлених у Apache VirtualHost. Ця конфігурація читається лише коренем - сподіваємось, ваш користувач Apache не працює як root.

Суть цього в тому, що тепер пароль знаходиться в змінній Global PHP.

Для зменшення цього ризику у нас є такі запобіжні заходи:

• Пароль шифрується. Ми розширюємо клас PDO, щоб включити логіку для розшифровки пароля. Якщо хтось читає код, де ми встановлюємо з'єднання, не буде очевидно, що з'єднання встановлюється зашифрованим паролем, а не самим паролем.
• Зашифрований пароль переміщується з глобальних змінних у приватну змінну . Додаток робить це негайно, щоб зменшити вікно, яке значення доступне у глобальному просторі.
• phpinfo()відключено. PHPInfo - це проста мета для отримання огляду всього, включаючи змінні середовища.

Помістіть пароль бази даних у файл, зробіть його лише для читання користувачеві, який обслуговує файли.

Якщо у вас є деякі засоби, які дозволяють лише дозволити процес роботи сервера PHP отримати доступ до бази даних, це майже все, що ви можете зробити.

Якщо ви говорите про пароль бази даних, на відміну від пароля, який надходить від браузера, стандартною практикою, здається, є встановлення пароля бази даних у конфігураційному файлі PHP на сервері.

Вам просто потрібно бути впевненим, що файл php із паролем має на нього відповідні дозволи. Тобто його слід читати лише веб-серверу та вашим обліковим записом користувача.

Просто помістити його в файл конфігурації десь так, як це робиться зазвичай. Просто переконайтесь, що ви:

1. заборонити доступ до бази даних з будь-яких серверів за межами вашої мережі,
2. стежте за тим, щоб випадково не показувати пароль користувачам (у повідомленні про помилку чи через файли PHP, які випадково подаються як HTML, etcetera.)

Ми вирішили це таким чином:

1. Використовуйте memcache на сервері з відкритим з'єднанням з іншого сервера паролів.
2. Збережіть, щоб запам'ятати пароль (або навіть весь файл password.php зашифрований) плюс ключ розшифровки.
3. Веб-сайт викликає клавішу memcache, що містить парольну фразу файлу паролів, і розшифровує в пам'яті всі паролі.
4. Сервер паролів кожні 5 хвилин надсилає новий зашифрований файл пароля.
5. Якщо ви використовуєте зашифрований password.php у своєму проекті, ви помістите аудит, щоб перевірити, чи цей файл торкнувся зовні - чи його переглянули. Коли це станеться, ви автоматично можете очистити пам'ять, а також закрити сервер для доступу.

Додатковим фокусом є використання окремого конфігураційного файла PHP, який виглядає так:

<?php exit() ?>

[...]

Plain text data including password

Це не заважає вам правильно встановити правила доступу. Але у випадку, коли ваш веб-сайт зламаний, "вимагати" або "включити" просто вийде зі скрипту на першому рядку, тому отримати дані ще складніше.

Тим не менш, ніколи не дозволяйте конфігураційним файлам у каталозі, до якого можна отримати доступ через Інтернет. У вас повинна бути папка "Веб", яка містить код контролера, css, зображення та js. Це все. Все інше зберігається в автономних папках.

Найкращий спосіб - це взагалі не зберігати пароль!
Наприклад, якщо ви перебуваєте в системі Windows і підключаєтесь до SQL Server, ви можете використовувати інтегровану автентифікацію для підключення до бази даних без пароля, використовуючи особу поточного процесу.

Якщо вам потрібно підключитися до пароля, спершу зашифруйте його, використовуючи сильне шифрування (наприклад, за допомогою AES-256, а потім захистіть ключ шифрування або використовуючи асиметричне шифрування і ОС захищає cert), а потім зберігайте його в файл конфігурації (за межами веб-каталогу) із потужними ACL .