--- title: "WordPress 6.8 przechodzi na bcrypt: co to oznacza dla projektów z wp-password-bcrypt?" url: "https://helloblog.io/pl/wordpress-6-8-bcrypt-wp-password-bcrypt/" date: "2025-02-20" modified: "2026-01-20" author: "Magdalena Wiśniewska" language: "pl_PL" categories: ["Bezpieczeństwo"] tags: ["bcrypt", "Bedrock", "bezpieczeństwo", "uwierzytelnianie", "WordPress"] featured_image: "https://helloblog.io/app/uploads/sites/8/2026/01/featured-8-1024x572.jpg" excerpt: "Jeśli w Twoim stacku (np. Bedrock) od lat siedzi \u0060wp-password-bcrypt\u0060, WordPress 6.8 praktycznie „zjada” jego funkcję. Sprawdź, co możesz bezpiecznie usunąć i dlaczego nie potrzebujesz żadnej migracji haseł." --- # WordPress 6.8 przechodzi na bcrypt: co to oznacza dla projektów z wp-password-bcrypt? W ekosystemie WordPressa rzadko zdarza się zmiana, która jednocześnie poprawia bezpieczeństwo i upraszcza utrzymanie projektu. WordPress 6.8 ma właśnie taki moment: rdzeń ma używać `bcrypt` jako domyślnej metody haszowania haseł użytkowników. To istotne, bo w wielu nowocześniejszych wdrożeniach (szczególnie opartych o Roots/Bedrock) ten temat był „łatany” zewnętrznie paczką `wp-password-bcrypt`. Poniżej rozkładam na czynniki pierwsze, co ta zmiana oznacza praktycznie: dla istniejących instalacji, dla deployów, dla zależności w Composerze i dla zespołów, które od lat polegały na tym dodatku. ## Co się zmienia w WordPress 6.8? (bcrypt w core) Zgodnie z zapowiedzią zespołu WordPress Core, od wersji 6.8 `bcrypt` ma być standardem w rdzeniu do haszowania haseł. `bcrypt` to sprawdzony, celowo „kosztowny” algorytm haszujący (z wbudowaną solą), zaprojektowany tak, żeby utrudniać ataki brute force i masowe łamanie hashy w razie wycieku bazy. W praktyce oznacza to, że poprawa bezpieczeństwa logowania i przechowywania haseł przestaje być czymś, co musisz dowozić pluginem/paczką. WordPress ma to zapewnić sam. ## Dlaczego wp-password-bcrypt przestaje być potrzebne? `wp-password-bcrypt` od Roots było odpowiedzią na realny problem: przez długi czas WordPress nie oferował równie mocnego haszowania haseł w standardzie, więc część zespołów wdrażała bcrypt „bokiem”. Ten pakiet robił to w sposób możliwie bezbolesny dla aplikacji. Skoro jednak WordPress 6.8 (i nowsze) ma natywnie obsługiwać bcrypt, dodatkowa warstwa staje się zbędna. Z punktu widzenia utrzymania projektu to dobra wiadomość: mniej zależności, mniej potencjalnych konfliktów i mniej elementów, które trzeba audytować. ## Najważniejsze: czy trzeba migrować hasła użytkowników? Nie. Jeśli Twoja strona działa na WordPressie 6.8 lub nowszym, możesz usunąć `wp-password-bcrypt` bez wykonywania migracji haseł. Istniejące hasła nadal będą działać, a rdzeń WordPressa ma przejąć uwierzytelnianie i obsługę bcrypt tam, gdzie to właściwe. #### Dobra wiadomość dla zespołów utrzymaniowych Brak migracji = brak okna serwisowego, brak resetów haseł i mniejsze ryzyko operacyjne przy aktualizacji. ## Co planuje Roots względem wp-password-bcrypt? Roots oficjalnie „wygasza” pakiet, bo jego rola została przejęta przez core WordPressa. W komunikacie zapowiedziano trzy konkretne kroki po stronie projektu: - oznaczenie `wp-password-bcrypt` jako **abandoned** na Packagist, - usunięcie odwołań do pakietu z Bedrocka i powiązanej dokumentacji, - zarchiwizowanie repozytorium na GitHubie. ## Co powinieneś zrobić w praktyce (checklista dla projektów na Composerze) Jeżeli utrzymujesz WordPressa przez Composer (np. Bedrock) i w zależnościach masz `roots/wp-password-bcrypt`, decyzja zależy głównie od tego, na jakiej wersji core działa produkcja. ### 1) Gdy produkcja jest na WordPress 6.8+ Możesz zaplanować usunięcie paczki z projektu. Z perspektywy działania logowania użytkowników nie powinno to wymagać dodatkowych kroków, bo core ma obsłużyć bcrypt bezpośrednio. ### 2) Gdy produkcja jest poniżej WordPress 6.8 Na starszych wersjach sytuacja się nie zmienia automatycznie. Jeśli dziś polegasz na `wp-password-bcrypt` dla wzmocnionego haszowania, to dopiero upgrade do 6.8 (lub wyżej) pozwoli Ci ten element bezpiecznie wyrzucić. Do tego czasu usunięcie zależności byłoby cofnięciem zabezpieczenia, które celowo wprowadziłeś. #### Uwaga na mieszane środowiska Jeśli masz kilka instancji (staging/production) na różnych wersjach WordPressa, uważaj, żeby nie usunąć paczki „za wcześnie” tylko dlatego, że staging już jest na 6.8. ## Dlaczego to jest realny krok do przodu dla bezpieczeństwa WordPressa? Największa wartość tej zmiany nie polega na tym, że bcrypt jest modny, tylko na tym, że staje się domyślnym standardem w core. Do tej pory wiele instalacji WordPressa działało „tak jak jest”, bez dodatkowych wtyczek/paczek bezpieczeństwa, bo właściciele stron często nie wiedzą, że takie rzeczy w ogóle trzeba rozważać. Włączenie bcrypt w rdzeniu sprawia, że wyższy poziom ochrony staje się powszechny, a nie elitarny (tylko dla tych, którzy świadomie dorabiali warstwę w Composerze). To też zmniejsza fragmentację: mniej różnych implementacji haszowania w zależności od tego, jakie dodatki ma dana instalacja. ## Podsumowanie 1. WordPress 6.8 ma używać bcrypt jako domyślnego haszowania haseł w core. 2. Jeśli jesteś na 6.8+, `wp-password-bcrypt` nie jest już potrzebne i można je usunąć. 3. Nie potrzeba migracji haseł — istniejące loginy powinny działać bez zmian. 4. Roots wygasza projekt: abandoned na Packagist, usunięcie wzmianek z Bedrocka i archiwizacja repozytorium. ## Odniesienia / Źródła - [Sunsetting wp-password-bcrypt with WordPress 6.8](https://roots.io/sunsetting-wp-password-bcrypt-with-wordpress-6-8/) - [WordPress 6.8 will use bcrypt for password hashing](https://make.wordpress.org/core/2025/02/17/wordpress-6-8-will-use-bcrypt-for-password-hashing/) - [wp-password-bcrypt](https://github.com/roots/wp-password-bcrypt) - [Bedrock](https://github.com/roots/bedrock) - [Discuss this post on Roots Discourse](https://discourse.roots.io/t/-/29282)