Uwierzytelnianie dwuskładnikowe, polityki haseł i bezpieczeństwo panelu administracyjnego PrestaShop

Back office PrestaShop to te jedne drzwi w Twoim sklepie, które otwierają dostęp do wszystkiego: danych klientów, historii zamówień, konfiguracji płatności, menedżera modułów pozwalającego uruchamiać dowolny kod PHP oraz eksportu bazy danych oddalonego o dwa kliknięcia. Dla większości atakujących znacznie skuteczniejsze jest wejście tymi drzwiami przy użyciu wykradzionych danych logowania niż szukanie podatności w kodzie — a w dużej liczbie sklepów te drzwi trzyma tylko jedno hasło, którego właściciel używa także do poczty i konta na forum wykradzionego trzy lata temu. Ten artykuł dotyczy utwardzenia właśnie tego logowania: drugiego składnika, zasad haseł, kont pracowników stojących za dostępem i sesji, która pozostaje aktywna po odejściu od ekranu. To warstwa kontroli dostępu w bezpieczeństwie. Pozostałe warstwy — uprawnienia plików, nagłówki, aktualizacje, filtrowanie botów — opisuje pełna lista kontrolna utwardzania bezpieczeństwa, a spokojniejsze, nietechniczne omówienie znajdziesz w prostym przewodniku dla właścicieli sklepów.

Zweryfikowano w czerwcu 2026 r. pod kątem zachowania back office PrestaShop 1.6, 1.7, 8 i 9 oraz aktualnych wytycznych NIST dotyczących haseł.

Skąd naprawdę wyciekają logowania administratorów

Zanim sięgniesz po narzędzia, warto nazwać konkretne błędy, bo każdy z nich wymaga innego rozwiązania — i to rozwiązania dopasowanego do PrestaShop:

• Ponowne używanie danych logowania. Najczęstsze włamanie nie ma nic wspólnego z kodem PrestaShop. Hasło administratora wyciekłe z niepowiązanej usługi jest automatycznie próbowane na stronie AdminLogin. Hasło nigdy nie zostało „złamane” — zostało znalezione.
• Współdzielone konta. Jeden login admin@ używany przez trzy osoby oznacza, że dziennik aktywności przypisuje każdą zmianę do tego samego wpisu, a Ty nie możesz odebrać dostępu jednej osobie bez zablokowania pozostałych.
• Zbyt szerokie uprawnienia pracowników. Pracownik pakujący zamówienia z prawami SuperAdmina staje się luką wielkości SuperAdmina, jeśli ktoś wyłudzi dostęp do jego laptopa — od początku nie powinien mieć dostępu do menedżera modułów.
• Brak drugiego składnika. Samo hasło to pojedynczy punkt awarii. Phishing, keylogger albo jedno ponownie użyte hasło wystarczą.
• Sesje, które nigdy się nie kończą. Back office pozostawiony otwarty na współdzielonym lub skradzionym komputerze to uwierzytelniona sesja, z której może skorzystać każdy.

Wszystko poniżej przypisuje po jednym rozwiązaniu do jednego z tych problemów. Żadne z nich nie wymaga modyfikowania plików rdzenia.

Uwierzytelnianie dwuskładnikowe w back office PrestaShop

Uwierzytelnianie dwuskładnikowe rozdziela logowanie na coś, co znasz (hasło), i coś, co masz (kod z telefonu). Wykradnij jedno, a nadal nie przejdziesz przez drugie. W PrestaShop typowa droga do 2FA w back office prowadzi przez zaufany moduł bezpieczeństwa albo zewnętrzną warstwę kontroli dostępu przed ekranem logowania — dlatego najpierw trzeba ustalić, jak dodasz tę ochronę, a nie tylko gdzie kliknąć.

Jak w praktyce dodaje się 2FA do back office

Nie zakładaj, że rdzeń Twojej wersji ma gotowy przełącznik uwierzytelniania dwuskładnikowego. Zasadniczo PrestaShop 1.6, 1.7 i 8 wymagają zaufanego modułu zewnętrznego albo zewnętrznej warstwy kontroli dostępu, aby dodać drugi składnik do back office. Traktuj 2FA jako „natywne” tylko wtedy, gdy potwierdzisz to dla dokładnie swojej wersji docelowej w oficjalnej dokumentacji danego wydania — funkcja obecna w jednej wersji podrzędnej nie dowodzi, że istnieje w tej, której używasz.

Praktyczne opcje, w przybliżeniu od najłatwiejszej:

• Zaufany moduł bezpieczeństwa administracji, który dodaje TOTP (rotacyjny sześciocyfrowy kod z aplikacji uwierzytelniającej, takiej jak Google Authenticator, Authy, Microsoft Authenticator, 1Password albo KeePass z wtyczką TOTP). To najczęstsza droga i jedyna, która daje prawdziwy drugi składnik oparty na aplikacji osobno dla każdego pracownika.
• Zewnętrzna warstwa kontroli dostępu — proxy SSO/tożsamościowe albo WAF/reverse proxy, które wymaga drugiego składnika, zanim żądanie w ogóle dotrze do PrestaShop. Chroni to powierzchnię logowania bez dotykania rdzenia.
• Lista dozwolonych adresów IP (poniżej) jako kontrola kompensująca tam, gdzie nie możesz wdrożyć żadnej z powyższych opcji — to nie jest prawdziwy drugi składnik, ale radykalnie zmniejsza powierzchnię ataku.

Włączanie 2FA

Niezależnie od wybranej drogi kroki konfiguracji znajdują się we własnych ustawieniach danego modułu lub proxy, a nie na stałym ekranie rdzenia — dlatego postępuj zgodnie z instrukcją konkretnego narzędzia, które wdrażasz. Dla składnika z aplikacji uwierzytelniającej (TOTP) proces zwykle wygląda tak:

• Włącz drugi składnik dla własnego konta w ustawieniach modułu lub proxy.
• Zeskanuj kod QR aplikacją uwierzytelniającą, a następnie wpisz aktualny kod z powrotem, aby potwierdzić synchronizację zegara. Dobrze zbudowane narzędzie nie zapisze ustawienia, dopóki nie potwierdzisz kodu, więc nie zablokujesz sobie dostępu przez błędnie zeskanowany sekret.
• Zapisz i przetestuj: wyloguj się i zaloguj ponownie. Po podaniu hasła system powinien poprosić o rotacyjny kod.

Dwie uwagi operacyjne, które oszczędzają realnych problemów. Po pierwsze, TOTP zależy od zgodności zegarów telefonu i serwera w niewielkim oknie czasu; jeśli kody są odrzucane, zanim uznasz funkcję za zepsutą, sprawdź poprawność czasu serwera (NTP). Po drugie, jeśli Twój moduł 2FA lub proxy udostępnia kody odzyskiwania/zapasowe, przechowuj je poza telefonem — jako wpis w menedżerze haseł, nie na karteczce. Jeśli ich nie udostępnia, zawczasu opisz jego własną procedurę odzyskiwania dostępu, bo zgubiony lub wyczyszczony telefon bez planu awaryjnego może oznaczać interwencję na poziomie bazy danych (wyczyszczenie odpowiednich kolumn 2FA, często w wierszu ps_employee), żeby odzyskać dostęp.

Uczyń 2FA obowiązkowym, a nie opcjonalnym

Jeden pracownik bez 2FA to słabe ogniwo, na którym wisi cały łańcuch: atakujący, który dostanie się na dowolne konto, zyskuje punkt zaczepienia do eskalacji. Narzędzie, którego użyjesz, zwykle włącza drugi składnik osobno dla każdej osoby, zamiast wymuszać go globalnie na wszystkich kontach, więc „obowiązkowe” jest polityką, którą egzekwujesz przez sprawdzanie, czy każdy aktywny pracownik ma 2FA włączone. Jeśli masz kilku pracowników i chcesz, aby rejestracja była wymuszana (nowa osoba nie może pracować, dopóki jej nie skonfiguruje), szukaj modułu lub warstwy kontroli dostępu z obsługą wymuszonej rejestracji. Zwłaszcza w 1.6 i wczesnych 1.7 moduł albo zewnętrzna warstwa to droga inna niż ograniczenie logowania po adresie IP.

Polityka haseł zgodna z aktualnymi wytycznymi

Celem nie są „skomplikowane” hasła, lecz hasła, których nie da się odgadnąć, ponownie wykorzystać ani masowo próbować. Współczesne wytyczne (NIST i inne) odeszły od dawnego teatru złożoności i rotacji w stronę długości oraz unikalności.

Praktyczna instrukcja dla zespołu jest krótka: każde konto back office używa unikalnego, losowo wygenerowanego hasła przechowywanego w menedżerze (Bitwarden, 1Password, KeePass). Losowy ciąg 20 znaków jest jednocześnie silniejszy i wygodniejszy w codziennym użyciu niż „sprytne” hasło do zapamiętania, bo nikt nie musi go wpisywać ani pamiętać. To, jak PrestaShop przechowuje takie hasło, zależy od wersji: współczesne wydania używają silnego algorytmu haszowania haseł (haszowanie z kosztem obliczeniowym stojące za PrestaShop\PrestaShop\Core\Crypto\Hashing), więc wyciek bazy danych nie ujawnia tekstu jawnego — ale starszy PrestaShop 1.6 używał słabszego mechanizmu opartego na kluczu cookie. Jeśli nadal pracujesz na 1.6, traktuj przechowywane hasze jako ochronę o ograniczonej wartości: zaplanuj aktualizację lub migrację, aby hasła zostały ponownie zahaszowane nowoczesnym algorytmem, a do tego czasu szczególnie mocno polegaj na unikalnych, silnych hasłach. Tak czy inaczej, haszowanie jest bezwartościowe, jeśli hasło brzmiało admin123 i znajduje się w publicznej liście słów.

Jest też jedna kontrola specyficzna dla PrestaShop, którą warto znać: przepływ resetowania hasła jest ograniczany przez wartość konfiguracyjną PS_PASSWD_TIME_BACK (liczba minut między żądaniami resetu dla back office), więc atakujący nie może spamować wiadomościami resetującymi. Rzadko trzeba ją zmieniać, ale istnieje.

Konta pracowników: jedna osoba, jeden login, najmniejsze potrzebne uprawnienia

To błąd, który po cichu podważa każdą inną kontrolę. Model uprawnień PrestaShop jest naprawdę sprawny — problem prawie zawsze polega na tym, że pozostaje szeroko otwarty.

Jedno konto na jednego człowieka

Każda osoba otrzymuje własny rekord pracownika w Parametry zaawansowane → Zespół → Pracownicy. Daje to trzy korzyści naraz: ścieżkę audytu, która pokazuje, kto co zrobił (PrestaShop zapisuje działania względem wykonującego je pracownika), możliwość dezaktywowania dostępu jednej odchodzącej osoby bez zmieniania haseł wszystkim pozostałym oraz 2FA per osoba. Współdzielone loginy odbierają wszystkie trzy.

Profile i zasada najmniejszych uprawnień

Uprawnień w PrestaShop nie ustawia się bezpośrednio na pracowniku — ustawia się je w Profilu (w Parametry zaawansowane → Zespół → Uprawnienia), a każdemu pracownikowi przypisuje się profil. Zbuduj profile odpowiadające rzeczywistym rolom, a siatka Podgląd / Dodawanie / Edycja / Usuwanie zrobi resztę:

Liczą się dwie zasady: ogranicz profil SuperAdmin do właściciela i najwyżej jednej zaufanej osoby technicznej, oraz pamiętaj, że uprawnienie Moduły w praktyce oznacza prawo wykonywania kodu — każdy, kto może zainstalować moduł, może uruchomić PHP na Twoim serwerze, więc traktuj je jak krytyczne uprawnienie, a nie wygodę do rozdawania.

Zabezpieczenie samej powierzchni logowania

Dwa składniki chronią dane logowania; poniższe mechanizmy chronią drzwi, które one otwierają.

Zachowaj losową nazwę folderu administracyjnego

PrestaShop instaluje back office w losowym katalogu (czymś w rodzaju /admin47ab9c/) właśnie po to, aby boty nie mogły znaleźć go przez zgadywanie /admin albo /backoffice. Zachowaj tę losowość. Jeśli podczas migracji folder został przemianowany na coś przewidywalnego, zmień jego nazwę na dysku, a PrestaShop automatycznie użyje nowej ścieżki — ukrycie nie jest samo w sobie kontrolą bezpieczeństwa, ale usuwa Cię ze strumienia automatycznych skanów uderzających w oczywiste ścieżki.

Ograniczaj tempo i obserwuj nieudane logowania

Narzędzia do brute force i credential stuffing polegają na możliwości szybkiego wykonania tysięcy prób. Stosuje się tu dwie linie obrony: na krawędzi aplikacji dodaj wyzwanie do formularza logowania, aby zautomatyzowane narzędzia się zatrzymały — opisuje to artykuł reCAPTCHA dla PrestaShop. Na krawędzi sieci ogranicz, kto w ogóle może dotrzeć do logowania. Jeśli zespół loguje się ze stałego adresu IP biura albo przez VPN, lista dozwolonych adresów w .htaccess lub firewallu dla katalogu administracyjnego blokuje każde inne źródło bez względu na poprawność hasła — ta i pozostałe reguły serwerowe są opisane w regułach bezpieczeństwa i wydajności .htaccess dla PrestaShop. W każdym wariancie przeglądaj wzorzec nieudanych logowań: seria błędów z jednego adresu IP na jedno konto pracownika to atak w toku.

# Apache 2.4, inside the randomized back-office directory
Require ip 203.0.113.10
Require ip 198.51.100.0/24

Ekran zablokowanych prób Total Defender wyświetla wpisy według typu, powodu, adresu IP i daty oraz informuje o braku zablokowanych prób w ciągu ostatnich 24 godzin.

Bezpieczeństwo sesji: część, o której wszyscy zapominają

Możesz zrobić wszystko powyżej, a mimo to przekazać atakującemu uwierzytelnioną sesję, jeśli back office pozostanie otwarty i zalogowany na niestrzeżonym komputerze. Zamykają to trzy kontrole:

• Limit bezczynności. PrestaShop wygasza sesje back office na podstawie ustawienia PS_COOKIE_LIFETIME_BO (czas życia ciasteczka administracyjnego). Ustaw go na tyle krótko, aby ekran pozostawiony bez nadzoru sam się wylogował — krócej dla współdzielonych stanowisk, dłużej tylko tam, gdzie komputer rzeczywiście jest prywatny.
• Administracja wyłącznie przez HTTPS. Back office musi być dostępny przez HTTPS, aby ciasteczka sesji nie dało się podsłuchać w sieci kawiarni lub hotelu. Jeśli Twój sklep nie działa jeszcze w całości po HTTPS, napraw to najpierw — instrukcja znajduje się w artykule o konfiguracji SSL i HTTPS w PrestaShop.
• Bezpieczne ciasteczka HttpOnly. Gdy cała strona działa po HTTPS, ciasteczko sesji administratora powinno mieć flagi Secure i HttpOnly, aby nigdy nie było wysyłane jawnym tekstem i nie mogło być odczytane przez JavaScript — skradzione ciasteczko oznacza obejście 2FA, więc to nie jest opcjonalne.

Aktualny czas życia ciasteczka back office możesz sprawdzić bezpośrednio w bazie danych; wartość jest przechowywana w dniach:

SELECT name, value
FROM ps_configuration
WHERE name IN ('PS_COOKIE_LIFETIME_BO', 'PS_PASSWD_TIME_BACK');

Monitoruj back office, nie tylko front sklepu

PrestaShop zapisuje część zdarzeń i błędów back office, a ten dziennik jest użytecznym sygnałem wczesnego ostrzegania — ale traktuj go jako zapis częściowy, nie pełną ścieżkę audytu ani SIEM. Dziennik w aplikacji pokaże takie rzeczy jak nowe konto pracownika, którego nie utworzyłeś, nagła zmiana uprawnień albo nieoczekiwana edycja konfiguracji płatności. Sam z siebie nie daje jednak wiarygodnego monitoringu logowań według adresu IP ani kraju: wychwycenie „logowania o 04:00 z kraju, w którym nie działasz” zwykle wymaga korelacji logów dostępowych serwera, dedykowanego modułu bezpieczeństwa albo logów WAF/reverse proxy, gdzie zapisywany jest źródłowy adres IP. Wyrób sobie nawyk przeglądania dziennika w aplikacji — minimum raz w miesiącu, raz w tygodniu przy rotacji pracowników — i połącz go z tym logiem serwerowym, który pokazuje źródło uwierzytelnienia. Jeśli już podejrzewasz, że etap ostrzeżeń minął i trwa aktywna kompromitacja, przestań czytać porady o utwardzaniu i skorzystaj z planu reakcji na incydent w artykule reakcja na naruszenie danych: co zrobić, gdy Twój sklep zostanie zhakowany.

Jeśli nie możesz wdrożyć modułu 2FA

Wiele sklepów utknęło na zamrożonej konfiguracji — starej wersji utrzymywanej przez przestarzały motyw, stary moduł albo wersję PHP, którą aktualizacja by zepsuła — gdzie dodanie modułu bezpieczeństwa jest kłopotliwe. Nadal masz opcje: zaufany moduł może dodać drugi składnik tam, gdzie pasuje, zewnętrzna warstwa kontroli dostępu może stanąć przed logowaniem, lista dozwolonych adresów IP może odgrodzić back office, a reszta porad dotyczących kontroli dostępu działa bez zmian. Szersza strategia utwardzania sklepu, którego naprawdę nie możesz jeszcze ruszyć — wirtualne łatanie i kontrole kompensujące — to osobny temat opisany w zaawansowanym utwardzaniu PrestaShop dla sklepów, których nie możesz jeszcze zaktualizować.

10-minutowe zabezpieczenie administracji, krok po kroku

• Włącz 2FA na własnym koncie SuperAdmin już teraz, przez moduł bezpieczeństwa lub warstwę kontroli dostępu, i potwierdź, że opcja odzyskiwania jest zapisana poza urządzeniem.
• Wypisz wszystkich aktywnych pracowników. Wyłącz współdzielone loginy; każdemu człowiekowi daj własne konto.
• Otwórz Uprawnienia i obniż poziom każdemu, kto nie potrzebuje SuperAdmina. Sprawdź, że ma go tylko 1–2 osoby i że dostęp do Modułów jest mocno ograniczony.
• Przeprowadź każdą pozostałą osobę przez włączenie jej własnego 2FA.
• Potwierdź, że każde hasło administratora jest unikalne i wygenerowane przez menedżer haseł — zmień wszystkie, które takie nie są.
• Sprawdź, czy nazwa folderu administracyjnego nadal jest losowa, a nie /admin.
• Zaostrz czas życia ciasteczka back office, aby bezczynne sesje były wylogowywane.
• Potwierdź, że administracja działa wyłącznie po HTTPS, a ciasteczko sesji ma flagi Secure + HttpOnly.
• Przeczytaj logi administracyjne z jednego miesiąca. Zanotuj, jak wygląda „normalność”, żeby następnym razem nienormalne zdarzenia od razu się wyróżniały.

Najczęściej zadawane pytania

Czy PrestaShop ma wbudowane uwierzytelnianie dwuskładnikowe dla back office?

Nie zakładaj tego dla swojej wersji. PrestaShop 1.6, 1.7 i 8 zazwyczaj wymagają zaufanego modułu bezpieczeństwa administracji albo zewnętrznej warstwy kontroli dostępu (proxy SSO/tożsamościowego albo WAF przed logowaniem), aby dodać drugi składnik do back office. Traktuj 2FA jako natywne tylko wtedy, gdy potwierdzisz to w oficjalnej dokumentacji dokładnie swojego wydania — funkcja w jednej wersji podrzędnej nie dowodzi, że istnieje w tej, której używasz.

Co się stanie, jeśli zgubię telefon z aplikacją uwierzytelniającą?

Jeśli Twoje narzędzie 2FA oferuje kody odzyskiwania lub zapasowe, przechowujesz je poza telefonem (jako wpis w menedżerze haseł) i używasz jednego, aby wrócić do panelu. Jeśli ich nie oferuje, korzystasz z udokumentowanej procedury odzyskiwania, która w wielu konfiguracjach oznacza interwencję na poziomie bazy danych — wyczyszczenie odpowiednich kolumn 2FA w wierszu ps_employee, aby wyłączyć drugi składnik dla tego konta, zalogować się i zarejestrować je ponownie. Dlatego ścieżkę odzyskiwania ustala się przed włączeniem 2FA, a nie po.

Czy powinienem wymuszać wygasanie haseł administratorów co 90 dni?

Nie. Aktualne wytyczne (NIST i inne) porzuciły zaplanowaną rotację, bo popycha ludzi do schematu Summer2024! → Summer2025!, który jest słabszy, nie silniejszy. Zmieniaj hasło tylko przy podejrzeniu kompromitacji. Włóż wysiłek w długość i unikalność: losowo wygenerowany, nigdy nieużywany ponownie ciąg 16+ znaków z menedżera haseł, osobny dla każdego konta.

Czy zmiana nazwy folderu administracyjnego naprawdę ma sens?

Warto utrzymać ją losową, ale nie warto robić z tego obsesji. PrestaShop już instaluje back office w losowym katalogu, aby boty nie mogły znaleźć go przez zgadywanie /admin albo /backoffice; jeśli migracja zostawiła u Ciebie przewidywalną nazwę, zmień nazwę folderu na dysku, a PrestaShop użyje nowej ścieżki. To ukrycie, nie pełna kontrola bezpieczeństwa — usuwa Cię ze strumienia automatycznych skanów, ale zasługuje na miejsce tylko obok 2FA, silnych haseł i ograniczania prób logowania.

Jak zatrzymać ataki brute force i credential stuffing na logowanie?

Zabezpiecz dwie krawędzie. Na krawędzi aplikacji dodaj wyzwanie do formularza logowania (reCAPTCHA), aby zautomatyzowane narzędzia się zatrzymały. Na krawędzi sieci ogranicz, kto w ogóle może dotrzeć do logowania — jeśli zespół loguje się ze stałego adresu IP biura albo przez VPN, lista dozwolonych adresów w .htaccess lub firewallu dla katalogu administracyjnego odrzuca każde inne źródło, niezależnie od poprawności hasła. Żadne z tych rozwiązań nie zastępuje 2FA, które ratuje sytuację, gdy wycieknie prawdziwe hasło.

Co to realnie daje?

Przejdź przez tę listę, a ekonomia ataku na Twój sklep się zmieni. Credential stuffing zatrzyma się na drugim składniku. Wyłudzone hasło będzie bezużyteczne bez telefonu. Przejęte konto pracownika pakującego zamówienia nie dotrze do menedżera modułów. Laptop pozostawiony bez nadzoru sam się wyloguje. Nic z tego nie wymaga programisty, edycji rdzenia ani aktualizacji, na którą nie możesz sobie pozwolić — to konfiguracja back office i menedżer haseł. Sami budujemy moduły bezpieczeństwa i prowadzimy sklepy, więc uczciwe ujęcie jest takie: back office to miejsce, w którym naruszenie z niedogodności zmienia się w katastrofę, a kontrola dostępu jest najtańszą godziną o największym wpływie, jaką możesz na to poświęcić. Gdy będziesz gotowy utwardzić warstwy pod logowaniem — pliki, nagłówki, aktualizacje, ruch botów — pełna lista kontrolna utwardzania będzie mapą dla reszty.