Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Czy należy wymuszać okresową zmianę haseł? Mamy chyba ostateczne rozwiazanie problemu.
Temat powraca dość często, więc postanowiliśmy podsumować aktualny stan wiedzy. Otóż obecne branżowe rekomendacje nie zalecają regularnych (np. co 30 czy 180 dni) zmian haseł.
Microsoft (Security baseline (FINAL) for Windows 10 v1903 and Windows Server v1903):
Usuwamy polisy dotyczące wygasania haseł, które wymagają okresowych jego zmian.
Kiedy użytkownicy są zmuszani do zmian haseł, zbyt często robią drobne zmiany lub używają przewidywalnych schematów do modyfikacji swojego hasła i / lub zapominają nowego hasła
Ostatnie badania naukowe kwestionują wartość pewnych zakorzenionych w środowisku praktyk dotyczących haseł takich jak okresowe wygasanie haseł i wskazują na lepsze alternatywy
Dropping the password-expiration policies that require periodic password changes.
When humans are forced to change their passwords, too often they’ll make a small and predictable alteration to their existing passwords, and/or forget their new passwords
Recent scientific research calls into question the value of many long-standing password-security practices such as password expiration policies, and points instead to better alternatives
OWASP Application Security Verification Standard 4.0 (bazujący na wytycznych NIST):
2.1.10 Verify that there are no periodic credential rotation or password history requirements.
NIST Digital Identity Guidelines, 800-63-B:
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Warto też zauważyć, że wiele źródeł nie wymaga już używania w hasłach odpowiedniego zestawu znaków (np. minimum jeden znak specjalny, cyfra, mała, duża litera), obecnie bardziej nacisk kładzie się na długość hasła (min 12 znaków) oraz niewystępowanie samego hasła w tych popularnych czy wyciekniętych. OWASP ASVS 4.0:
2.1.1 Sprawdź czy hasła użytkowników mają co najmniej 12 znaków
2.1.1 Verify that user set passwords are at least 12 characters in length
2.1.9 Sprawdź czy system nie posiada ograniczenia na znaki, które mogą być użyte w haśle. Sprawdź czy nie ma wymagań używania dużej / małej litery czy cyfry bądź znaku specjalnego w haśle
2.1.9 Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters
2.1.7 Sprawdź czy hasła ustawiane przez użytkowników weryfikowane są pod kątem bazy wyciekłych haseł lub popularnych haseł
2.1.7 Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system’s password policy) or using an external API.
–ms
Dokładnie takie zmiany wprowadziłem w jednej z firm, narażając się oczywiście na święte oburzenie ISO-audytorów i miłośników reguł zamiast zdrowego rozsądku.
Mam nadzieję, że to pomoże w aktualizacji myślenia – o ile nie jest za późno.
@Kingu nie pakuj wszystkich audytorów ISO do jednego wora, ja nim jestem i od co najmniej roku proszę podczas audytów o uzasadnienie utrzymywania w/w polityk, czyli tych 30 dniowych i 8 znakowych – ani jednego admina nie spotkałem, któremu zależałoby na zmianie pokłosia po Rozporządzeniu … pozdro
A ja nigdy rej bzdurnej zasady ie wymagałem. Dobrze, że chociaż od roku.
Bo od roku z kawałkiem to nie jest twardy obowiązek prawny. Ale obowiązkiem jest przeanalizowanie i udokumentowanie tej analizy – czy wymuszać zmianę, jak często, w jakich przypadkach itd
jak zmusić AD do sprawdzania hasła pod kątem bazy wyciekłych haseł lub popularnych haseł ???
obecnie pewnie się nie da, choć poczytaj: https://blogs.technet.microsoft.com/secguide/2019/05/23/security-baseline-final-for-windows-10-v1903-and-windows-server-v1903/
Może tak
https://jacksonvd.com/checking-for-breached-passwords-in-active-directory/
lub
https://jacksonvd.com/checking-for-breached-passwords-ad-using-k-anonymity/
Dodam, że nie testowałem tego rozwiązania.
Dlaczego nie powinno być wymogu co do małych/dużych liter, cyfr etc.? :o
Btw. czasem dziwi mnie limit znaków w haśle ustawiony na np. 16 (max 16 ;). O ile dobrze pamiętam na platformie Origin tak było (jest?).
Jeszcze troche, a tak zwane „autorytety”, wszem i wobec ogloszą że „bardzo nie dobrą praktyką jest stosowania skomplikowanych haseł”. Jak widać, wygoda userów nade wszystko. I nie tylko userów. Co nie których administratorów także. Wszem i w obec promuję się managery haseł, jednocześnie narzekając na to, że użytkownicy posiadają takie samo hasło do wielu serwisów. A do managera haseł, który stanowj przecież pewnego rodzaju „sejf na hasła” również stosuję się raczej pojedyncze hasło. Można oczywiście wyobrazić sobie klucz sprzętowy, jednak jest to jednak dodatkowy koszt.
W organizacji w której pracuje, hasła zmienaine są co tydzień do wszystkich kont. Już sobie wyobrażam jęki co po niektórych „autorytetów” „jejku, co tydzień? ile to roboty, jaka nie wygoda”. Taka polityka, już niejednokrotnie uchroniła firme przed bardzo poważnymi problemami. Może dopowiem tylko że pewnego razu, osoba która pozyskała hasłą dostępu do kilku systemów, nie była w stanie poczynić większych szkód, właśnie poprzez wymuszoną politykę okresowej zmiany haseł.
Sądzę że nie wygoda użytkownika powinna być najważniejsza lecz interes danej organizacji. KML napisał „To jest na prawdę duży news. Dobra wiadomość :). Zgadzam się. Jest to bardzo dobra wiadomość dla wszelkiego rodzaju napastników.
Zdaję sobie sprawę że byc może wszelkiego rodzaju „autorytety” za chwile przygniotą muj post jakimiś wydumanymi kontrafaktami typu „jak masz xxxxxx pod sobą to nied a rady, itp itd” Da rade drodzy koledzy, da rade nawet prezesa przekonać :)
To może trzeba pójść o poziom wyżej i zacząć zmieniać wszystkie hasła codziennie? Pomyśl jak to by podniosło poziom bezpieczeństwa w twojej firmie! :)
A co za problem? Włączasz komputer i ustawiasz hasło „jedno sesjowe”! A co za problem? Każde zalogowanie się do systemu po raz pierwszy, wymusza zmianę hasła! A czy nie może wymuszać nadanie hasła? I za każdym razem? Ale można efektywniej! Prawie każda firma posiada karty dostępu. Co za problem aby aktywować klawiaturę czy nawet niektóre polecenia systemowe za pomocą takiej karty? Idziesz do kibelka? Drzwi wc-tu z korytarza musisz otworzyć kartą, co wymusza zabranie karty, a w efekcie wylogowuje użytkownika z aplikacji oraz systemu. I można dalej snuć dywagacje… Ale wszyscy wolą szybciej i łatwiej! A jak wiadomo, wygoda użyszkodnika jest przeciwieństwem bezpieczeństwa systemu…
Akurat co do tego, żeby często zmieniać hasła to się nie zgodzę. Trzeba zmieniać, ale rozsądnie.
Częsta zmiana może mieć jakieś plusy zakładając, że:
– hasło nie wyciekło ze źródła, które cały czas jest dostępne (np. niewykryta luka w oprogramowaniu)
– jakimś cudem ludzie będą ustalać hasła losowe, długie, z różnymi znakami (mimo zmieniania co chwilę, ciężko).
Pozostaje wtedy kwestia gdzie to super trudne hasło co chwilę zmieniane będzie przechowywane? W karteczce w kieszeni? Na monitorze? Pod klawiaturą? A może w pliku tekstowym na pulpicie? :D
Częsta zmiana haseł, tak jak w artykule zostało to napisane, powoduje, że stają się one słabe co właśnie ułatwia życie włamywaczom.
Jeśli rzadko zmieniasz hasła, ale za są one silne (adekwatnie do ryzyka) to jesteś w stanie pamiętać te 15-25 różnych znaków ;)
Serio myślisz, że osoba, która pozyskała hasło o wzorcu „MojeHasloOd11Do17@listopada” nie domyśli się, że następne w kolei będzie zmienione na 18Do24?
Polityka haseł powinna być rozsądna. Bo inaczej ludzie będą w ramach swojej wygody dopisywać takie kwiatki według przewidywalnych algorytmów; bo serio – oni się chcą zająć swoją pracą, a nie użeraniem się z systemami IT. A tej mentalności nie zmienisz, nawet horrendalnymi karami umownymi.
A czemu odchodzi się od wymagań dot. wymuszeń każdej grupy znaków? Bo to doprowadza do haseł w stylu Abcd@1234, żeby ten głupi system w końcu się odczepił ;]
@maxc, pochwal się jeszcze gdzie pracujesz dla pełnego obrazu sytuacji. Nie dobrą praktyką jest robienie na podstawie podmiotów szczególnie wrażliwych, reguł dla wszystkich. Nie każda firma ma potrzebę tracić
kupe kasy na wątpliwe zabezpieczenia.
O tym czy zmiana haseł ma sens decyduje po części sposób ich pozyskania. Jeżeli ktoś uzyskał nie powołany dostęp raz, to jaką masz gwarancje że nie zdobędzie następnego hasła? Częsta zmiana haseł zwiększa ryzyko wykrycia intruza, ale sama w sobie niczemu nie zapobiega a wręcz ułatwia uzyskanie dostępu.
A potem ludzie dzwonią do admina:
– Panie Maksiu, Grażynka z tej strony… sprzątaczka wciągnęła mi kartkę z hasłem, zresetuje mi Pan?
20 lat zajęło wciąż nie wszystkim wdrażanie wymuszania zmiany hasła oraz sprawdzania jego skomplikowania. Więc teraz kolejne 10 zajmie wdrażanie nowych wytycznych :)
A jakie jest uzasadnienie?
Jak się bronić przed bazami haseł pochodzacych z wycieków?
masz na myśli np. to? https://sekurak.pl/manager-hasel-1password-podpowiada-czy-jakies-z-twoich-hasel-nie-zostalo-skompromitowane/
Chodzi mi raczej o to jakie jest uzasadnienie, że nie warto wymuszać zmiany haseł. Rozumiem, że badania potwierdzają sposoby radzenia sobie z tym przez userów. Ale czy faktycznie to jest bezpieczniejsza praktyka? W przypadku MS zakładam, że to mas sens jeśli stosujemy jakiś dodakowy składnik.
Jak czyjeś hasło będzie skompromitowane i ktoś trzeci zacznie go używać to okresowa zmiana hasła pozwala w jakimś stopniu to ograniczyć. Więc ponownie, czy ktoś pomoże mi zrozumieć jakie jest merytoryczne uzasadnienie takiego wyboru? (a nie tego jak user się zachowuje)
Zawsze możesz wpisać w google i zobaczyć co się stanie :)
Fajnie by było gdyby ostateczne. PCI dalej wymaga.
Tia, PCI niestety wciaz wymaga, a szkoda… juz mialem nadzieje ze przekonam pare osob do tego pomyslu a tu szkoda :)
Ps. dajcie znac jak sie cos zmieni :D
To jest na prawdę duży news. Dobra wiadomość :)
To jeszcze przydałoby się pozbyć maskowanych haseł.
Czy nie uważacie że okresowa zmiana haseł redukuje powierzchnię ataków pth ptt które nadal są istotnym problemem w sieciach z centralnie sterowanym dostępem poprzez nałożenie ograniczeń czasowych w których takie hashe mogą zostać wykorzystane? Oczywiście można gdybac sobie czy w sytuacji kiedy ktoś pozyskał hash robi mu różnice okresowa zmiana hasła bo teoretycznie może pozyskać jeszcze raz, ale czy w praktyce tak wyglądają wszystkie albo większość scenariuszy?
Ogólnie Pr-owo hasło zdobyte raz ważne jest cały czas :)
A nawet hasz zdobyty raz ważny jest cały czas xD
To tak samo jak bieganie jest generalnie uznawane za zdrowe. A bieganie na smogu? ;)
Ktoś zabrał się za temat w aktualnych uwarunkowaniach i stwierdził że lepiej nie wymuszać zmianę haseł. Ryzyka są w obu wariantach: wymuszać / nie wymuszać. Trzeba to ~zmierzyć i wyważyć.
Nie rozmawiamy o smogu :)
Pytam serio ponieważ w standardach wiele jest zapisów robiących wrażenie jakby były tworzone na siłę, ten natomiast robi wrażenie stworzonego przez marketing „nie ma konieczności zmiany haseł ponieważ w naszym systemie hasła są bezpieczne” – sorry może trochę paranoja i dlatego lepiej skupić się na meritum.
Ja nie doradził bym np. w sieciach MS wyłączenia konieczności zmiany hasła
Tu nie chodzi o „wyłączanie konieczności zmiany hasła”. Chodzi o wymuszanie zmiany hasła raz na określony czas (np. co raz na 30 dni).
A co do logiki za tym poczytaj podlinkowany dokument NISTu + metodykę która za nim stoi. Tego nie da się wytłumaczyć szast prast w jedną minutę. Np. tłumacząc że użytkownicy jak muszą co chwilę zmieniać hasła to w końcu mają tego dość i hasło zapisują sobie gdzieś na karteczce albo wszędzie używają tego samego (z lekką mutacją).
Rozumiem złożoność problemu w całej rozciągłości nawet nad rozciągłości i w innych wymiarach też :) i dlatego uważam że ta rekomendacja nie zawsze musi być dobra
Widzę, że większość by chciała mieć jedną prostą regułę którą rozwiąże wszystkie problemy i którą można stosować bez myślenia w każdym przypadku.
Trzeba indywidualnie rozważyć czy to podejście jest dobre w danej organizacji. Dodać do siebie wszystkie plusy i minusy, i zobaczyć na którą stronę waga się wychyli. A jak stanie w miejscu to dopiero jest dramat ;]
MS to sobie może wypisywać wytyczne, ale w Azure weryfikują hasła w bazie wycieków. Dwa hasło ma być przynajmniej 12 znakowe i zmieniane co 90 dni. 3 ,MS i tu się z nimi zgodzę , forsuje rozwiązania z MFA i passwordless, gdzie autentykacja następuje za pomocą fizycznego elementu, telefonu , tokena itp. I to jest rozwiązanie bezpieczne, ale żeby uwolnić secret z urządzenia lub tokena musisz się zautoryzowac a tam co choćby PIN czyli hasło … Hehe
Ja hasła do Azure now zmieniałem od chyba roku. Na pewno nie w przeciągu ostatnich 90 dni.
Najzabawniejsze w okresowej zmianie haseł jest to, że szare ludki MUSZĄ zmieniać hasła co30dni, a admini co 180, o ile sobie tego nie wyłączą
Wierzyli ludzie, że hasła muszą być zmieniane, a teraz uwierzą, że haseł nie wolno zmieniać.
A ja w tych dokumentach widzę, że haseł nie należy zmieniać zbyt często (ale trzeba przeanalizować co to znaczy „zbyt”), że są lepsze sposoby niż okresowa zmiana hasła (ale trzeba je wdrożyć) itd.
Czyli nic nowego – konieczność i częstotliwość zmiany haseł należy dobrać indywidualnie do konkretnego przypadku.
Akurat jest to dość jasne napisane. Tj. że nie należy zmieniać hasła okresowo np. co 30 dni „bo tak”. A należy zmieniać np. jak wiesz że hasło wyciekło.
To też pamiętaj są rekomendacje, z którymi ktoś się nie musi zgodzić (bo np. ma specyficzną sytuację). Ale w takich przypadkach warto żeby ten ktoś to rozsądnie uzasadnił.
Gorzej jak nie wiesz, że wyciekło – a wyciekło :) .
Tu gdzie pracuję, jest wymuszenie co 30 dni. Więc powszechne są hasła z numerem miesiąca na końcu. Własnego imienia AD nie pozwala, więc najpierw imię dziecka, a potem miesiąc. Jako że AD pamięta ostatnie 24 hasła, to w jednym roku 12 haseł z imieniem córki, a w drugim – syna. I to ma być bezpieczeństwo? Już lepiej żeby hasło było zmieniane co pół roku, ale było zlepkiem losowych słów typu: „8przerwaNaKawe”.
he he, jak kiedyś pracowałem w korpo to system sprawdzał chyba 6 ostatnich haseł, a wymóg zmiany hasła był co 30 dni. Efekt był taki, że miałem swoje tajne hasło z dopiskiem 01-12 dla każdego miesiąca i tak co roku przez kilka lat z rzędu :D Można powiedzieć, że pomimo wymogu zmiany hasła co 30 dni to przez kilka lat miałem jedno i to samo hasło.
Sprawdzacz wyciekłych haseł do AD: https://safepass.me
Wkracza do akcji w momencie ustawiania/zmiany hasła.
Mamy, używamy w kilkunastu domenach w całej Europie. Działa, aczkolwiek parę dolców kosztuje. Na ten moment jedyne rozsądne rozwiązanie.
Do tego cykliczne sprawdzanie skryptem czy istniejące hasła w AD nie występują w bazie, ale to już autorskie rozwiązanie.
Przeraża mnie kwestia sprawdzania, czy hasło wyciekło, w serwisach typu haveibeenpwned.com. W celu sprawdzenia wysyła się im fragment hasha hasła. A taki fragment w zupełności wystarcza, by słownikowo spróbować zgadnąć to hasło – w końcu jeżeli crack wyświetli nawet kilkaset haseł, który mają taki sam ów fragment hasha, to sprawdzenie tych kilkuset haseł w docelowym serwisie długo nie potrwa.
@Bogdan, jesli chcesz sprawdzic konkretne haslo bez podawania nazwy uzytkownika, to byc moze tak jest. Ale jesli chcesz sprawdzic czy dane twojego konta i hash hasla kiedykolwiek wyciekly, to podajesz tylko adres email i masz info w jakich wyciekach ten email sie pojawil.