Polityka haseł powinna utrudniać przejęcie kont, nie czyniąc jednocześnie bezpiecznych zachowań niepotrzebnie trudnymi. Najlepsze polityki są jasne, praktyczne i dostosowane do realiów pracy użytkowników. Zachęcają do stosowania długich, unikatowych haseł, wspierają menedżery haseł, wymagają uwierzytelniania wieloskładnikowego tam, gdzie to możliwe i eliminują przestarzałe zasady, które skłaniają użytkowników do przewidywalnych zachowań.
\nW tym artykule znajdziesz zalecenia i zakazy nowoczesnej polityki haseł, wskazówki, czego unikać, najlepsze praktyki oraz gotowy szablon, który możesz dostosować do swojej organizacji.
\nPolityka haseł to zbiór zasad określających sposób tworzenia, przechowywania, używania, przekazywania, zmiany oraz ochrony haseł. Dotyczy pracowników, współpracowników, administratorów, kont usługowych i często też klientów, w zależności od objętych nią systemów.
\nDobra polityka haseł powinna odpowiadać na praktyczne pytania:
\nCelem nie jest stworzenie najbardziej skomplikowanego zestawu przepisów. Celem jest realne ograniczenie ryzyka.
\nDługość hasła to jedna z najskuteczniejszych ochron przed atakami zgadywania i brute-force. Jednolite minimalne wymaganie długości – np. dla wszystkich kont użytkowników – jest łatwiejsze do zrozumienia dla pracowników i egzekwowania przez IT niż osobne zasady dla różnych typów kont. Praktycznym minimum jest 16 znaków dla wszystkich kont użytkowników. Im dłuższe hasło (szczególnie przy korzystaniu z menedżerów haseł lub losowych fraz hasłowych), tym lepiej.
\nUżytkownicy powinni mieć możliwość ustawienia haseł znacznie dłuższych od minimum. Unikaj niskich limitów maksymalnej długości (np. 16 czy 20 znaków). Rozsądną bazową wartością jest co najmniej 64 znaki, a wiele systemów obsługuje znacznie więcej.
\nFrazy hasłowe powinny być dozwolone, pod warunkiem, że są wystarczająco długie i nie opierają się na powszechnie znanych cytatach, tytułach piosenek, nazwach firm czy przewidywalnych zwrotach. Fraza utworzona z kilku losowych słów zwykle jest lepsza niż krótkie hasło z wymuszonymi zamianami znaków.
\nKażde konto powinno mieć unikalne hasło. Ponowne używanie tego samego hasła to jeden z głównych powodów, dla których wyciek na jednej usłudze prowadzi do przejęcia konta na innej. Menedżer haseł czyni unikatowe hasła praktycznymi — użytkownik nie musi ich wszystkich zapamiętywać.
\nPolityka powinna wyraźnie dopuszczać i promować korzystanie z zatwierdzonych menedżerów haseł. Użytkownicy powinni móc wklejać hasła do formularzy logowania, używać autouzupełniania oraz generować losowe hasła. Blokowanie wklejania daje złudne poczucie bezpieczeństwa, ale często zniechęca do korzystania z silnych menedżerów haseł.
\nHasła należy odrzucać, jeśli znalazły się w publicznych wyciekach, na listach najczęściej używanych czy wewnątrzorganizacyjnych listach zabronionych haseł. Taka kontrola jest znacznie skuteczniejsza niż narzucanie użytkownikowi konieczności użycia wielkiej litery, cyfry i znaku specjalnego.
\nUwierzytelnianie wieloskładnikowe powinno być włączone, gdzie tylko się da, szczególnie dla administratorów, dostępu zdalnego, usług chmurowych, poczty e-mail, menedżerów haseł, systemów finansowych i innych kluczowych systemów. MFA nie zastępuje silnego hasła, ale ogranicza skutki przejęcia danych uwierzytelniających.
\nPreferuj metody odporne na phishing, takie jak passkeye, klucze sprzętowe (np. YubiKey) czy wbudowane uwierzytelnianie platformy. Aplikacje uwierzytelniające z kodami są zazwyczaj lepsze niż SMS. MFA przez SMS nie może być dopuszczone, jeśli istnieje jakakolwiek techniczna alternatywa, ponieważ numer telefonu może zostać przechwycony, przeportowany, podmieniony przez „SIM-swap” lub wykorzystany w procesach odzyskiwania konta.
\nTo nie teoria! W 2018 Reddit ujawnił, że atakujący przechwycili SMS-y z kodami dwuskładnikowymi i uzyskali dostęp do systemów wewnętrznych: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. W 2021 Coinbase zgłosiło, że atakujący wykradli kryptowaluty od co najmniej 6000 klientów, wykorzystując dane uwierzytelniające oraz słabość procesu odzyskiwania przez SMS: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
\nHasła powinny być zmieniane, gdy istnieją przesłanki lub uzasadnione podejrzenie przejęcia. Przykłady: phishing, złośliwe oprogramowanie na urządzeniu użytkownika, ujawnienie danych uwierzytelniających w wyniku wycieku, podejrzana aktywność logowania lub przypadkowe ujawnienie.
\nHasła współdzielone należy eliminować, gdzie tylko możliwe. Tam, gdzie jest to technicznie niemożliwe, muszą być one przechowywane w zatwierdzonym menedżerze haseł, dostęp ograniczony tylko do upoważnionych osób, a proces dzielenia, tam gdzie to możliwe, monitorowany i logowany.
\nReset hasła to często najsłabszy punkt bezpieczeństwa konta. Proces resetowania powinien weryfikować tożsamość, błyskawicznie wygasać linki tymczasowe, używać jednorazowych tokenów i informować użytkownika o zmianie hasła.
\nWymuszona zmiana hasła co 30, 60 czy 90 dni często prowadzi do ustawiania słabych haseł. Użytkownicy stosują wtedy łatwe do przewidzenia zmiany, np. dodanie cyfry czy zmiana sezonu. Wytyczne NIST (Digital Identity Guidelines) rezygnują z rutynowej zmiany haseł, wymagając jej wyłącznie w przypadku podejrzenia kompromitacji. Zobacz sekcję 3.1.1.2: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver. Wymagaj zmiany hasła po podejrzeniu przejęcia, zmianach roli, odzyskiwaniu konta lub gdy hasło nie spełnia już wymagań polityki.
\nZasady w rodzaju „musi zawierać wielką literę, małą literę, cyfrę i symbol” nie gwarantują siły hasła. Password1! spełnia te reguły, ale wciąż jest słabe. Istotna jest długość, unikalność, losowość i przesianie przez bazy wycieków.
Blokowanie wklejania utrudnia korzystanie z menedżerów haseł. Może to prowadzić do ustawiania krótszych, łatwiejszych do wpisywania haseł. Zezwalaj na wklejanie i autouzupełnianie, o ile nie istnieje konkretny, udokumentowany powód bezpieczeństwa.
\nPodpowiedzi często ujawniają zbyt dużo informacji. Skoro użytkownik jest w stanie przypomnieć sobie hasło z podpowiedzi, atakujący prawdopodobnie również. Stosuj bezpieczne procedury odzyskiwania dostępu zamiast podpowiedzi.
\nSystemy nie mogą przechowywać haseł w postaci jawnej lub w odwracalnym szyfrowaniu. Hasła należy haszować za pomocą nowoczesnych, powolnych algorytmów z solą, takich jak Argon2id, bcrypt, scrypt lub PBKDF2, zgodnie z możliwościami systemu i wymaganiami prawnymi.
\nSzybkie, ogólnego zastosowania algorytmy, jak MD5, SHA-1, SHA-256 czy SHA-512, nie są odpowiednie do haszowania haseł. Są projektowane do działania szybko, co ułatwia atakom siłowym po wycieku bazy danych. Więcej na temat ewolucji haszowania haseł znajdziesz w naszym artykule Ewolucja haszowania haseł.
\nHasła nie mogą być przesyłane e-mailem, komunikatorami, przez system ticketów, dokumenty czy zrzuty ekranu. Używaj menedżerów haseł z bezpiecznym udostępnianiem i kontrolą dostępu.
\nHasła nie mogą zawierać imion, dat urodzin, nazw firm, wzorców klawiatury, powtarzających się znaków czy popularnych zamienników np. @ zamiast a lub 0 zamiast o. Atakujący testują te wzorce w pierwszej kolejności.
Używaj prostych do zrozumienia wymagań:
\nKonta administratorów, usługowe oraz dostęp do produkcji wymagają surowszej kontroli. Wymagaj silniejszych haseł, MFA, ograniczonego dostępu, monitoringu i natychmiastowej rotacji po zmianach uprawnień.
\nSilne hasło nie zrekompensuje zbyt szerokich uprawnień. Użytkownik powinien mieć dostęp tylko do tych systemów i sekretów, które są niezbędne dla jego roli.
\nWykrywaj nietypowe logowania, niemożliwe przemieszczenia, powtarzające się nieudane próby, logowania z nowych krajów i dostęp poza typowymi godzinami. Polityka haseł powinna być wsparta monitoringiem oraz reagowaniem na incydenty.
\nSzkolenia powinny obejmować tematykę ponownego używania haseł, phishingu, fałszywych stron logowania, zmęczenia MFA, bezpiecznego dzielenia się hasłami i sposoby zgłaszania podejrzeń naruszenia bezpieczeństwa. Nie obwiniaj użytkowników — ułatwiaj bezpieczne zachowania.
\nPolityka haseł powinna być zrozumiała. Jeżeli jest zbyt długa, niejasna lub zbyt rygorystyczna, ludzie będą ją omijać. Najlepsza polityka to taka, którą da się realnie egzekwować i wdrażać.
\nPoniższy szablon jest punktem wyjścia. Dostosuj fragmenty w nawiasach do wymagań Twojej organizacji, systemów, poziomu ryzyka i wymogów prawnych.
\nPolityka haseł\n\nWersja: [1.0]\nWłaściciel: [Dział bezpieczeństwa / IT]\nData wejścia w życie: [RRRR-MM-DD]\nCykliczny przegląd: [co 12 miesięcy]\n\n1. Cel\n\nNiniejsza polityka definiuje wymagania dotyczące tworzenia, używania, przechowywania, udostępniania i zmiany haseł w [Nazwa organizacji]. Celem jest ograniczenie ryzyka nieautoryzowanego dostępu, kradzieży danych uwierzytelniających, przejęcia konta oraz utraty danych.\n\n2. Zakres\n\nPolityka dotyczy wszystkich pracowników, kontraktorów, pracowników tymczasowych, usługodawców i wszystkich innych osób, które uzyskują dostęp do systemów, aplikacji, sieci, usług chmurowych lub danych [Nazwa organizacji].\n\nPolityka dotyczy zwykłych kont użytkowników, kont uprzywilejowanych, kont usługowych, kont współdzielonych oraz każdego systemu, w którym do uwierzytelniania wykorzystywane są hasła.\n\n3. Wymagania dotyczące tworzenia haseł\n\nWszystkie hasła muszą spełniać następujące wymogi:\n\n- Konta użytkowników muszą posiadać hasła o długości co najmniej 16 znaków.\n- Hasła muszą być unikalne i nie mogą być używane ponownie ani w pracy, ani prywatnie.\n- Hasła nie mogą zawierać imion, nazw użytkownika, nazw firm, dat urodzin, wzorców klawiaturowych, powtarzających się znaków ani innych łatwych do odgadnięcia danych.\n- Hasła nie mogą opierać się na popularnych frazach, cytatach, tytułach piosenek ani przewidywalnych zamiennikach.\n- Hasła nie mogą występować w znanych wyciekach ani na listach najczęściej używanych haseł.\n- Hasła mogą zawierać spacje, symbole, cyfry, wielkie i małe litery.\n- Długie frazy hasłowe są dozwolone, jeśli są unikalne i nie opierają się na przewidywalnych lub publicznie znanych frazach.\n\n4. Menedżery haseł\n\n[Nazwa organizacji] wymaga lub zdecydowanie zaleca korzystanie z zatwierdzonego menedżera haseł do tworzenia, przechowywania i udostępniania haseł.\n\nUżytkownicy mogą korzystać z generatora haseł, autouzupełniania oraz funkcji kopiuj–wklej w zatwierdzonym menedżerze haseł. Hasła nie mogą być przechowywane w przeglądarkach, arkuszach kalkulacyjnych, dokumentach, notatnikach, poczcie e-mail, komunikatorach, zrzutach ekranu ani w niezaufanych narzędziach.\n\n5. Uwierzytelnianie wieloskładnikowe\n\nWszędzie tam, gdzie jest to technicznie możliwe, należy włączyć uwierzytelnianie wieloskładnikowe (MFA), w szczególności dla:\n\n- Kont e-mailowych\n- Systemów zdalnego dostępu\n- Kont menedżera haseł\n- Usług chmurowych\n- Kont administracyjnych\n- Systemów finansowych, HR i innych systemów wysokiego ryzyka\n- Każdego systemu sklasyfikowanego jako [poufny / krytyczny]\n\nGdzie jest taka możliwość, użytkownicy powinni używać MFA odpornego na phishing, np. passkey, kluczy sprzętowych lub autoryzatorów platformowych. Preferowane są aplikacje uwierzytelniające zamiast SMS. MFA przez SMS jest zabronione, jeśli dostępna jest jakakolwiek silniejsza metoda MFA — wyjątek to wyłącznie brak możliwości technicznych dla innej opcji.\n\n6. Zmiana haseł\n\nHasła muszą być zmienione natychmiast, jeśli:\n\n- Hasło jest znane lub istnieje podejrzenie, że zostało przejęte.\n- Użytkownik wpisał hasło na stronie podejrzanej o phishing.\n- Hasło zostało udostępnione osobie nieuprawnionej.\n- Na urządzeniu wykryto malware lub nieautoryzowany dostęp.\n- Hasło występuje w znanym wycieku danych.\n- Użytkownik uprzywilejowany zmienia rolę lub kończy współpracę.\n- Dział IT lub Bezpieczeństwa nakazuje zmianę hasła.\n\nNie wymaga się rutynowej zmiany haseł, chyba że wymuszają to przepisy prawa, kontrakty lub ograniczenia systemowe. Hasła nie mogą być zmieniane przez wprowadzanie przewidywalnych, małych zmian w poprzednim haśle.\n\n7. Udostępnianie haseł\n\nHasła nie mogą być udostępniane poprzez e-mail, komunikatory, systemy ticketowe, dokumenty, zrzuty ekranu, rozmowy telefoniczne lub ustnie.\n\nKonta współdzielone są dopuszczalne tylko wtedy, gdy konta indywidualne są technicznie niemożliwe lub gdy taka współdzielona tożsamość została zatwierdzona przez [Dział bezpieczeństwa / IT]. Zatwierdzone konta współdzielone muszą być przechowywane i udostępniane za pomocą zatwierdzonego menedżera haseł z ograniczonym dostępem tylko dla uprawnionych osób.\n\n8. Konta uprzywilejowane\n\nKonta uprzywilejowane muszą mieć unikalne hasła, które nie są używane na żadnym zwykłym koncie użytkownika. Na tych kontach należy włączyć MFA, gdzie tylko możliwe, i regularnie je przeglądać.\n\nHasła do kont uprzywilejowanych muszą być rotowane, gdy administrator opuszcza organizację, zmienia rolę, nie potrzebuje już dostępu lub jeśli istnieje podejrzenie kompromitacji.\n\n9. Konta usługowe i sekrety aplikacji\n\nHasła do kont usługowych, klucze API, tokeny oraz sekrety aplikacji muszą być przechowywane w zatwierdzonym systemie zarządzania sekretami lub menedżerze haseł.\n\nPoświadczenia kont usługowych nie mogą być umieszczane w kodzie źródłowym, plikach konfiguracyjnych, obrazach, dokumentacji czy skryptach, chyba że są zabezpieczone zatwierdzonym procesem zarządzania sekretami.\n\n10. Reset haseł oraz odzyskiwanie konta\n\nProcesy resetowania haseł muszą weryfikować tożsamość użytkownika przed przywróceniem dostępu. Linki do resetu i tymczasowe hasła muszą być jednorazowe, szybko wygasać i być przekazywane wyłącznie dozwolonymi kanałami.\n\nUżytkownik musi być powiadomiony o każdej zmianie lub resecie hasła. Tymczasowe hasło musi być zmienione przy pierwszym logowaniu.\n\n11. Zabezpieczenia techniczne\n\nSystemy, które przechowują lub przetwarzają hasła, muszą:\n\n- Nigdy nie przechowywać haseł w postaci jawnej.\n- Haszować hasła przy użyciu aktualnego, solonego algorytmu: PBKDF2, scrypt, bcrypt lub Argon2.\n- Nie używać MD5, SHA-1, SHA-256, SHA-512 ani innych szybkich algorytmów ogólnego użytku wyłącznie jako funkcji hashującej hasła.\n- Zabezpieczać punkty końcowe logowania przez limity prób (rate limiting) lub równoważne mechanizmy.\n- Odrzucać hasła słabe, przewidywalne, powszechnie używane i występujące w wyciekach.\n- Pozwalać użytkownikom na wklejanie haseł z menedżera haseł.\n- Obsługiwać rozsądną długość hasła, co najmniej 64 znaki tam, gdzie to możliwe.\n- Logować zdarzenia związane z bezpieczeństwem procesu uwierzytelniania.\n\n12. Zgłaszanie podejrzeń naruszenia bezpieczeństwa\n\nUżytkownicy muszą niezwłocznie zgłaszać podejrzenie przejęcia hasła, phishing, nietypowe monity o logowanie, monity MFA, których nie inicjowali, lub przypadkowe ujawnienie hasła do [kontakt Bezpieczeństwo / IT].\n\n13. Wyjątki\n\nWyjątki od niniejszej polityki muszą być udokumentowane, poddane ocenie ryzyka, ograniczone czasowo i zatwierdzone przez [kierownictwo bezpieczeństwa / IT]. Tam, gdzie to możliwe, należy stosować środki kompensujące.\n\n14. Egzekwowanie\n\nNieprzestrzeganie niniejszej polityki może skutkować usunięciem dostępu, obowiązkowym szkoleniem, konsekwencjami dyscyplinarnymi lub innymi środkami zgodnymi z politykami [Nazwa organizacji] i obowiązującym prawem.\n\n15. Przegląd\n\nPolityka musi być przeglądana co najmniej raz w roku lub po istotnych zmianach w systemach, zagrożeniach, przepisach prawa lub działalności organizacji.\nSilna polityka haseł nie polega na utrudnianiu życia użytkownikom. Jej celem jest eliminacja słabych nawyków, wspieranie menedżerów haseł, stosowanie MFA i szybka reakcja na ujawnienie poświadczeń. Polityka musi być praktyczna, egzekwowalna i skoncentrowana na realnych zagrożeniach, takich jak phishing, credential stuffing, ponowne użycie haseł oraz konta, których dane wyciekły.
","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"Polityka haseł: zalecenia, zakazy, najlepsze praktyki i gotowy szablon do wdrożenia","description":"Dowiedz się, czego powinna wymagać nowoczesna polityka haseł, jakich przestarzałych zasad należy unikać i skopiuj praktyczny szablon dla swojej organizacji.","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"pl","langPathPrefix":"/pl"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}