Я відповідаю за безпеку багатьох спільних хостинг-серверів. Більшість із них мають веб-сайти WordPress. На кожному сервері є щонайменше 500 веб-сайтів WordPress.

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

Тепер мій план - з’ясувати слабкий пароль веб-сайту WordPress і насильно змінити пароль адміністратора на інший надійний пароль. Таким чином, WordPress можна захистити, і мій сервер не матиме проблем.

Який спосіб дізнатися міцність збереженого пароля WordPress?

Bruteforce хеши

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

WordPress використовує phpass для хешування. За замовчуванням WordPress не використовує видува або подібне, а лише md5 з кількістю ітерацій 8192. Якщо ви просто хочете знайти справді погані паролі, грубе посилення, безумовно, можливо.

Але я вважав би це досить великим порушенням довіри, яку надають користувачі до вас, тому я б не рекомендував такий підхід.

Проаналізуйте їх паролі під час входу

Ви можете додати скрипт, який перехоплює всі запити до скриптів входу в WordPress, а також ввійти або проаналізувати паролі, оскільки вони знаходяться в простому тексті в той момент.

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

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

Запровадити політику щодо паролів (і змусити користувачів змінювати свої паролі)

Ви можете застосувати політику щодо пароля. Коли користувач подає новий пароль, ви перевірите, чи він відповідає вашій політиці чи ні (в ідеалі це станеться на стороні сервера, а не на стороні клієнта через JavaScript).

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

Звичайно, на старі паролі політика не впливає, тому потрібно змусити користувачів змінювати свої старі паролі, щоб відповідати політиці

Обмежити пошкодження

Використання надійних паролів, безумовно, може бути хорошою ідеєю, але в ідеалі зламаний екземпляр WordPress не повинен насправді впливати на вас як веб-майстра.

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

Це досить широка тема, але деякі моменти включають: DISALLOW_FILE_EDITобмеження використання плагінів (оскільки вони набагато менш надійно кодовані, ніж сам WordPress), заборонити JavaScript (наприклад, для мультисайтів, лише супер-адміністратори мають право публікувати JavaScript, а не адміністратори) тощо.

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

На мій досвід, сценарій для міцності пароля знаходиться в www.example.com/wp-admin/js/password-strength-meter.js, і це посилання на нього.

Тут ви можете змінити рівні та відсотки для паролів, щоб ви могли встановити обов'язкову силу пароля на 100/100.

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

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

Хороша новина полягає в тому, що ви можете змінювати паролі користувачів, погані новини - ви не можете їх бачити.
Wordpress настільки потужний, що навіть у базі даних він зберігає пароль з одним способом шифрування, це не просто хеш md5, який ви можете конвертувати, це навіть не серіалізовані дані, для пароля test123ви отримаєте щось на кшталт $P$BjW8o9Dm1vC5bwAcP1iAdNVm0lbvn, навіть якщо ви зміните поле пароля в базі даних без використання шифрування це не працюватиме.

Як змінити пароль

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

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

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

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

І ні, немає швидкого способу дізнатися пароль на тиждень на сайті 500 wordpress. Йосип згадував одне посилання, щоб перевірити міцність пароля, але цей сайт не використовував криптовалуту md5 для перевірки міцності пароля.

Ознайомтесь із цим посиланням SO ( Wordpress за допомогою MD5 ), і ви побачите, що вихід відрізняється від додатка. Отже, як ви бачите, p#aSS*Word14це не безпечно, Dance With Me Tonightтому не використовуйте програму thirt party для перевірки пароля Wordpress, оскільки, можливо, вони використовують інший крипто алгоритм для перевірки / припущення міцності пароля.

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

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

Як вказували попередні відповіді: ви не можете прочитати збережені паролі.

Альтернативним рішенням може бути:

1. Реалізуйте пропозицію Йосипа Івича щодо застосування надійних паролів.
2. Видаліть усі паролі (або лише паролі для користувачів з певними привілеями).
3. І нарешті, повідомте постраждалих користувачів про те, що діє нова політика щодо паролів, і направте їх /wp-login.php?action=lostpasswordна скидання паролів.

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

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

Порада: WordPress все ще вміє правильно його хеш, навіть якщо ви оновите MD5 (% пароль%) у стовпчик sql.

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

1) Оновіть паролі лише для адміністраторів, редакторів, але щоб ви вимагали, щоб знайти, хто такі користувачі. Надішліть їм електронну пошту, а потім застосуйте обмеження пароля на сторінці скидання пароля / сторінці реєстрації тощо. Пам'ятайте, хтось може мати ці форми в інших місцях на сайті (думаю, що також AJAX форми). Створення команди WP-CLI, яка допоможе вам тут виконувати цей план, а не завантажувати WP-середовище та виконувати сценарії.

2) Створення таблиці веселки, яка складається з хешованих паролів для відомого рядка (пароля). І тоді ви в основному повинні зіставити хешування з паролем конкретного користувача та оцінити силу цього пароля. Створення таблиці - це найповільніший крок тут, оскільки вам доведеться хешувати кожен можливий пароль, який він може бути, зберігати його на диску (кілька ГБ залежно від довжини та комбінації паролів, які ви обліковуєте), а потім діяти на результати. 99% впевнені, що це рішення про надмірний рівень для ваших потреб.

Порада: Ви знаєте ті солі та секрети, які ми маємо wp-config.php. Змінення їх визнає недійсним зареєстровані сесії, на всякий випадок, якщо вам це знадобиться.

Спробуйте жорстоко змусити його за допомогою словникової атаки

Який кращий спосіб оцінити міцність пароля? :-) Так, я знаю, пройде певний час ...

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

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