Як зберігати ім'я користувача та пароль для API у варіанті БД Wordpress?


19

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

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

Отже, моє запитання полягає в тому, як я зберігаю цей чутливий біт інформації? Хешинг вийшов, тому це має бути якесь шифрування.

У WordPress є унікальний ключ, який можна використовувати, який відрізнятиметься від блогу до блогу? Які функції php потрібно використовувати для шифрування та дешифрування? Я шукаю функції, які швидше за все будуть працювати у всіх встановленнях WP.


3
Це свого роду нерозв'язне. Не має значення, скільки ви шифруєте, якщо це потрібно реверсувати. Якщо WP може розшифрувати його і WP порушено, шифрування не має значення.
Рарст

Але чому ваш API повинен знати пароль? Чи недостатньо, якщо API знає, що користувач знає пароль?
onetrickpony

1
@One Trick Pony - пароль потрібно зберігати, щоб процес можна було автоматизувати без втручання користувача.
Брейді

1
@Rarst - Я знаю, що якщо WP порушено, то і паролі. Я не можу цього запобігти. Я можу запобігти тому, що якщо виходить дамп SQL, то паролі не в простому тексті.
Брейді

@Brady так, якщо тільки SQL-дамп порушений, то шифрування допоможе. Однак я вважаю такий сценарій малоймовірним. Якщо у вас є доступ до бази даних, це неприємно і для компрометації WP.
Рарст

Відповіді:


4

Хоча я погоджуюсь з попередніми відповідями, щоб відповісти на запитання, яке ви насправді задали, те, що спадає на думку, це використовувати одну з цих констант для wp-config.php:

визначити ('AUTH_KEY', 'відредаговано');
define ('SECURE_AUTH_KEY', 'відредаговано');
define ('LOGGED_IN_KEY', 'відредаговано');
визначити ('NONCE_KEY', 'відредаговано');

Вони мають бути унікальними для всіх установок Wordpress - і стосуються єдиних варіантів попередніх клавіш, які можна знайти в wordpress. Альтернативою було б додати власну схожу константу, яка будується шляхом переміщення одного з них на адресу електронної пошти адміністратора чи подібного - а потім зберігати його у прихованому параметрі налаштування - для захисту від втрати ключа, якщо хтось випадково змінить ключі після вашого плагін встановлений. Небезпека полягає в тому, що якщо вони не були унікальними при початковій установці, але власник адміністратора / сайту вирішив виправити помилку після факту, вони не повинні випадково порушити шифрування пароля.

Що стосується функцій шифрування / дешифрування - швидкий пошук Google повертає такий перелік із кодом, який, як видається, відповідає законопроекту: http://maxvergelli.wordpress.com/2010/02/17/easy-to-use-and-strong- шифрування-дешифрування-php-функції /

функція шифрування ($ input_string, $ ключ) {
    $ iv_size = mcrypt_get_iv_size (MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
    $ iv = mcrypt_create_iv ($ iv_size, MCRYPT_RAND);
    $ h_key = хеш ('sha256', $ ключ, TRUE);
    повернути base64_encode (mcrypt_encrypt (MCRYPT_RIJNDAEL_256, $ h_key, $ input_string, MCRYPT_MODE_ECB, $ iv));
}

функція дешифрування ($ encrypted_input_string, $ key) {
    $ iv_size = mcrypt_get_iv_size (MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
    $ iv = mcrypt_create_iv ($ iv_size, MCRYPT_RAND);
    $ h_key = хеш ('sha256', $ ключ, TRUE);
    повернення обрізки (mcrypt_decrypt (MCRYPT_RIJNDAEL_256, $ h_key, base64_decode ($ encrypted_input_string), MCRYPT_MODE_ECB, $ iv));
}

Ось деяка документація шифрування AES, що використовується тут: http://www.chilkatsoft.com/p/php_aes.asp


4

Саме ця обставина була розроблена OAuth.

На домашній сторінці OAuth :

Для розробників постачальника послуг ...

Якщо ви підтримуєте ...

  • веб-додатки
  • API на стороні сервера
  • машапи

Якщо ви зберігаєте захищені дані від імені користувачів, вони не повинні поширювати свої паролі по Інтернету, щоб отримати доступ до них. Використовуйте OAuth, щоб надати користувачам доступ до своїх даних, захищаючи дані облікового запису.

Перевага OAuth полягає в тому, що вам не потрібно зберігати пароль користувача. Коли вони вперше налаштовують плагін, їх пропонують увійти з іменем користувача та паролем через програму (зазвичай це сторінка, розміщена на тому самому сервері, що і API, і завантажена або в переспрямування сторінки, товсту скриньку або рамку) .

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

Якщо ви хочете побачити приклад цього в дії, перегляньте Jetpack .

Коли ви активуєте плагін, він скаржиться, що він не підключений. Коли ви "підключите" його, ви вводите свої облікові дані через WordPress.com та встановлюєте взаємодію OAuth між WordPress та їх API.

Але робити це потрібно лише один раз, і ваше ім'я / пароль WordPress.com ніколи не зберігається у вашій локальній базі даних WordPress.


1
Було б добре використовувати це, але API, з яким я маю справу, не мій, і у них немає системи OAuth.
Брейді

1
У такому випадку ваш єдиний реальний варіант - визнати, що вам потрібно зберігати пароль у БД, і незалежно від того, шифруєте чи ні, він насправді не суттєво відрізняється від безпеки. Як уже згадувалося вище, якщо він знаходиться в db, і шифрування є оборотним, то кожен, хто має доступ до WordPress (легітимний або зламаний), міг би захопити його.
EAMann

0

Це важливе питання, оскільки багато сервісів досі не підтримують OAuth та зберігання паролів у базі даних параметрів робить їх читабельними для кожного окремого плагіна Wordpress (див. Мій коментар вище).

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

Основна ідея, яка змушує мене думати, що шифрування паролів можливо, полягає в наступному:

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

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

Насправді розшифрування зробити досить просто: припустимо, у нас вже є зашифрована версія стороннього сервісу, що зберігається в базі даних, ми можемо підключитися до 'authenticate'фільтра або перезаписавши wp_authenticate()функцію, створити солоний хеш простого тексту користувача паролем (за засоби wp_hash_password()), зберігайте хешований пароль як ключ шифрування десь приватним, поки користувач не вийде (використовуйте 'wp_logout'гачок, щоб видалити ключ), і використовуйте його щоразу, коли нам потрібен сторонній пароль для розшифрування зашифрованого значення в базі даних.

Хоча я маю відчуття, що це має бути можливим зробити цю роботу, проте є кілька невирішених проблем:

  1. Як зробити шифрування? Потенційно, ви можете зберігати звичайний текстовий пароль, поки користувач не вийде і знову і не зробить шифрування протягом 'authenticate'. Користувачеві може бути запропоновано увійти в систему, щоб зберегти період, поки цього не стане коротко.
  2. Де зберігати ключ і як його видалити під час виходу? Я правильно розумію, що 'authenticate'це запускається лише тоді, коли користувач насправді входить у систему?
  3. Якщо зараз є спосіб зберігати хешований пароль, можливо, можна замість цього отримати ключ із сеансового файлу cookie?
  4. Хто обробляє зміни пароля? Схоже , можна вловити такі зміни пароля, а пароль третьою стороною , може потім бути повторно шифрується за допомогою ключа , отриманого з нового пароля.
  5. Чи є спосіб надати підтримку кількох користувачів? В ідеалі хочеться, щоб користувач адміністратора міг встановлювати сторонні паролі в налаштуваннях, які потім можуть бути подані в позов щодо менш привілейованих користувачів для взаємодії з сторонніми послугами, в ідеалі навіть без розголошення цих паролів. Для цього користувачеві адміністратора потрібно було б мати можливість генерувати ключі для всіх користувачів, які ці інші користувачі можуть створювати лише для себе. Це якось можливо?
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.