zmiana adresu logowania

Zmiana adresu logowania to zastąpienie domyślnego adresu logowania WordPressa, czyli /wp-login.php i przekierowania z /wp-admin, adresem wybranym przez właściciela strony. Zwykle robi to wtyczka, na przykład WPS Hide Login, albo opcja wtyczki bezpieczeństwa ^[4]. Dokumentacja WordPressa ocenia, że ukrycie adresu logowania może zmniejszyć szum, ale nie powinno być jedyną obroną ^[1]. Jest to przykład podejścia security through obscurity.

Jak działa

WordPress buduje adres logowania funkcją wp_login_url(), która dokleja wp-login.php do adresu witryny i przepuszcza wynik przez filtr login_url ^[5]. Wtyczki zmieniające adres korzystają z takich mechanizmów, a do tego przechwytują żądania do starych adresów. WPS Hide Login deklaruje, że nie zmienia nazw plików rdzenia ani nie dodaje reguł przepisywania adresów, tylko przechwytuje żądania stron; wp-login.php i katalog wp-admin stają się niedostępne dla niezalogowanych ^[4]. Wyłączenie wtyczki przywraca stronę do stanu sprzed jej instalacji ^[4].

Różnicę między botem a administratorem pokazuje schemat poniżej.

RYS. 1Bot i administrator po zmianie adresu

W WordPressie

Każda instalacja WordPressa ma formularz logowania pod tym samym adresem, co czyni go naturalnym celem automatów. Dokumentacja opisuje atak siłowy (brute-force) jako najprostszy sposób włamania: napastnik powtarza próby kombinacji nazwy użytkownika i hasła, aż któraś zadziała ^[1]. Próby są zautomatyzowane i często rozproszone przez botnety, więc nawet nieudane ataki mogą przeciążyć stronę ^[1].

Porównanie zmiany adresu z innymi zabezpieczeniami logowania zestawia tabela.

Zmiana adresu nie obejmuje innych dróg logowania. Plik xmlrpc.php jest częstym celem ataków siłowych, zwłaszcza przez metodę system.multicall ^[1]. Jeśli XML-RPC nie jest potrzebny, dokumentacja zaleca go wyłączyć, a jeśli jest używany, ograniczyć i objąć ścisłym limitem żądań ^[1]. Adres logowania może też ujawnić się w inny sposób: WPS Hide Login zastrzega, że nie działa z wtyczkami i motywami, które mają adres wp-login.php wpisany na stałe ^[4]. Autorzy deklarują natomiast zgodność z instalacjami Multisite, zarówno na subdomenach, jak i w podkatalogach, oraz z wtyczkami BuddyPress, bbPress i Jetpack ^[4]. Przed wdrożeniem na stronie ze sklepem, forum albo logowaniem przez aplikację mobilną warto sprawdzić wszystkie ścieżki logowania na kopii strony.

Znaczenie

MITRE opisuje słabość CWE-656 jako mechanizm ochrony, którego siła zależy głównie od tego, że pozostaje nieznany, więc jego poznanie wystarcza do obejścia ^[3]. Ta sama definicja przyznaje, że ukrywanie może być małą częścią obrony warstwowej, bo daje napastnikowi więcej pracy, ale staje się poważnym ryzykiem, gdy jest główną ochroną ^[3]. Dokumentacja utwardzania WordPressa mówi podobnie: security through obscurity jest na ogół złą strategią podstawową, choć w niektórych miejscach ukrycie informacji może pomóc ^[2].

Praktyczne korzyści są dwie. Pierwsza to możliwe mniejsze obciążenie serwera, bo masowe żądania do /wp-login.php nie trafiają do formularza logowania. Druga to czytelniejsze logi: w dzienniku zostają próby tych, którzy znają właściwy adres, a nie tysiące przypadkowych botów ^[1]. Nie zmienia to siły samego uwierzytelnienia. Hasło, które da się odgadnąć przez credential stuffing, pozostaje słabe niezależnie od adresu formularza.

Jak się bronić

Zmiana adresu logowania to dodatek do podstawowych zabezpieczeń, a nie ich zamiennik ^[1]. Dokumentacja WordPressa wymienia jako kluczowe środki ^[1]:

• silne, unikalne hasła i menedżer haseł;
• uwierzytelnianie dwuskładnikowe dla wszystkich administratorów, dodawane wtyczką, bo rdzeń WordPressa go nie zawiera;
• rozważenie kluczy passkey dla logowania odpornego na phishing;
• ograniczanie tempa prób logowania na brzegu sieci albo na serwerze;
• CAPTCHA na formularzu logowania;
• ochronę albo wyłączenie XML-RPC;
• aktualny rdzeń, motywy i wtyczki oraz monitorowanie anomalii logowania.

MITRE dla CWE-307 wymienia rozłączanie po kilku nieudanych próbach, opóźnienia między próbami, czasową blokadę konta i zadanie obliczeniowe po stronie użytkownika, takie jak CAPTCHA ^[6]. Dokumentacja WordPressa zaleca też, by nie używać nazwy użytkownika admin ^[1], a dokumentacja utwardzania dodaje webmaster do nazw atakowanych w pierwszej kolejności ^[2]. Pomaga to także przeciw enumeracji użytkowników.

Kto zmienia adres logowania, powinien zapisać go w bezpiecznym miejscu. WPS Hide Login podaje dwie drogi odzyskania dostępu po zapomnieniu adresu: odczyt wartości whl_page w tabeli opcji bazy danych albo usunięcie katalogu wtyczki, zalogowanie przez wp-login.php i ponowną instalację ^[4].

-- Odczyt ustawionego adresu logowania WPS Hide Login (prefiks tabel może być inny)
SELECT option_value FROM wp_options WHERE option_name = 'whl_page';

Historia i przykłady

Starsze poradniki zalecały rozbudowane przepisywanie adresów w .htaccess, blokady całych krajów i Basic Auth na całym katalogu /wp-admin ^[1]. Aktualna dokumentacja WordPressa, zaktualizowana w lutym 2026 roku, ocenia te metody jako zawodne albo psujące wtyczki oparte na AJAX i zaleca zamiast nich WAF na brzegu sieci, 2FA, passkeys i celowane ograniczanie tempa żądań ^[1]. Ukrycie adresu logowania pozostało w tej dokumentacji jako wskazówka o ograniczonym znaczeniu ^[1]. Sama wtyczka WPS Hide Login ma w katalogu WordPress.org ponad 2 miliony aktywnych instalacji ^[4]. Pokrewne zabezpieczenia opisują hasła ochrona przed atakami brute force (brute force protection) i zabezpieczenia w .htaccess.