WordPress 6.8 прави bcrypt стандарт: време е да махнем wp-password-bcrypt

В WordPress света рядко се случва промяна, която едновременно да е значима за сигурността и да намалява външните зависимости. С WordPress 6.8 точно това става: bcrypt става стандартният метод за хеширане на пароли в ядрото. Практическият резултат за много от нас е прост — пакетът wp-password-bcrypt (Roots) вече няма смисъл да стои в проекта.

Какво се променя в WordPress 6.8 (и защо е важно)

bcrypt е утвърден алгоритъм за хеширане на пароли, който е проектиран да бъде „бавен“ по контролируем начин. Това го прави много по-устойчив при brute-force атаки върху откраднати хешове в сравнение с по-стари подходи. До момента в WordPress екосистемата bcrypt често се добавяше чрез плъгин/пакет (например wp-password-bcrypt), за да се постигне по-добра защита без да се чака промяна в core.

Според обявените планове за WordPress 6.8 bcrypt вече влиза в ядрото като default за password hashing. Това е голяма стъпка напред за автентикацията в WordPress и намалява нуждата от допълнителни „security“ добавки само заради паролите.

Какво означава това за wp-password-bcrypt

Roots официално обявиха, че с WordPress 6.8 пакетът wp-password-bcrypt става излишен за сайтове, които са на 6.8 или по-нова версия. С други думи:

• Ако проектът ти работи на WordPress 6.8+, можеш спокойно да премахнеш wp-password-bcrypt.
• Не е нужна миграция на пароли и не се очакват „масови“ ресетвания — съществуващите пароли продължават да работят.
• WordPress core ще поеме автентикацията и ще използва bcrypt там, където е приложимо.

Какво ще направят Roots оттук нататък

За да отразят промяната, Roots планират няколко конкретни стъпки около пакета:

• Ще маркират wp-password-bcrypt като abandoned в Packagist.
• Ще премахнат референциите към него от Bedrock и свързаната документация.
• Ще архивират GitHub репото.

Това е добър сигнал и за поддръжката в дългосрочен план: когато core поеме дадена функционалност, външните пакети логично се „затварят“, за да не се поддържат изкуствено.

Практичен checklist за екипи с Composer/Bedrock

Ако поддържаш WordPress през Composer (например Bedrock), най-важното е да вържеш премахването на пакета към реалната версия на WordPress в production.

1. Провери целевата версия на WordPress в проекта (и реално в production). Ако вече си на 6.8+, можеш да планираш премахване.
2. Премахни зависимостта от wp-password-bcrypt от composer.json и изпълни composer update/composer install според процеса ти.
3. Деплойни и провери стандартните потоци: login/logout, reset password, създаване на нов потребител, промяна на парола от профил.
4. Остави си бекъп/rollback план (както при всяка промяна в authentication слоя), но не очаквай нужда от миграционни скриптове за пароли.

Защо това е добра новина за сигурността (и за поддръжката)

Когато подобрение като bcrypt стане част от ядрото, печелим на няколко фронта: по-малко зависимости, по-малко „магия“ в authentication слоя и по-унифицирано поведение между инсталациите. За екипите това означава по-проста поддръжка и по-малко места, които трябва да следим за промени, CVE-та и compatibility проблеми.

Roots също поставят контекст: wp-password-bcrypt е създаден като прагматично решение във време, когато WordPress core не предлагаше достатъчно силно хеширане. След като core вече го има, най-правилният ход е пакетът да бъде пенсиониран.

Обобщение

• WordPress 6.8 въвежда bcrypt като default за password hashing в core.
• Ако сайтът ти е на 6.8+, wp-password-bcrypt вече не е нужен и може да се премахне без миграция на пароли.
• Roots ще маркират пакета като abandoned, ще го махнат от Bedrock и ще архивират репото.
• Ако си под 6.8, планирай ъпгрейд; дотогава не премахвай защита, на която разчиташ.