Pytanie brzmi: za co gorzej?

Przy opublikowanej polityce, możliwe hasła są mniejsze niż 64⁸ (~ 2,8 * 10¹⁴). W praktyce bardzo dużo haseł będzie prawdopodobnie [az] * 6 [0-9] [znak specjalny] (np. Aabaab1!) I podobnych.

Wszystkie możliwe hasła z tymi samymi znakami i długością mniejszą niż 8 to tylko 64⁷ + 64⁶ + 64⁵ + ... czyli ~ 4,5 * 10¹². To dużo mniej niż hasła o długości 8, więc nie zwiększa to zbytnio bezpieczeństwa, aby je umożliwić. (dopuszczenie dłuższych haseł oczywiście znacznie zwiększyłoby bezpieczeństwo)

Bez żadnej polityki wiele osób z pewnością będzie również używać złych haseł. Ale napastnik nie może być tego pewien. Ponadto niektórzy ludzie będą używać lepszych haseł.

Bez żadnej polityki atakujący nigdy nie może być pewien, jak trudno jest złamać hasło. Jeśli dasz mi bazę danych skrótów haseł, mogę spróbować ją złamać. Ale jeśli nie ma rezultatów, po pewnym czasie mogę przestać. Dzięki wdrożonej polityce mogę być pewien, że po 64 ^ 8 próbach mam wszystkie hasła.

Powiedziałbym, że polityka złych haseł jest gorsza. Ale to zależy od scenariusza ataku.

Ze zrzutem skrótów haseł, bez polityki dotyczącej haseł, jest bardzo prawdopodobne, że złamanie dowolnego hasła jest łatwiejsze, ale trudniej jest złamać większość haseł. Przy złej polityce, takiej jak podana , łatwiej jest złamać wszystkie hasła, ale najprawdopodobniej nieco trudniej jest złamać pierwsze.

Jeśli martwisz się, jak trudno jest złamać własne hasło, bez żadnej polityki możesz użyć bezpiecznego 20-znakowe losowe hasło, jeśli chcesz. Po wprowadzeniu tej polityki jesteś zmuszony do użycia niezabezpieczonego hasła. (w praktyce bardziej istotny jest sposób przechowywania haseł i tak dalej, ale to jest poza zakresem tutaj). Dlatego polityka złych haseł jest dużo gorsza jako użytkownik witryny / usługi.

Jeśli spojrzysz na to z organizacyjnego punktu widzenia, polityka złego hasła jest o wiele gorsza niż żadna.

Brak polityki dotyczącej haseł oznacza, że ​​prawdopodobnie nikt o tym nie pomyślał (niezbyt dobrze, że nie myślą o bezpieczeństwie, ale ok ...)

Ale polityka dotycząca złych haseł oznacza: Ktoś o tym pomyślał i wymyślił bzdury. Oznacza to, że prawdopodobnie nie mają pojęcia o bezpieczeństwie.

Ostatecznie, jeśli możesz wdrożyć politykę złych haseł, możesz również wdrożyć dobrą, więc nie ma wymówki dla polityki złych haseł. Sama zmiana polityki na „Hasło musi mieć co najmniej 8 znaków” znacznie zwiększyłaby bezpieczeństwo i nie jest trudna do zrobienia.

Teraz zastanawiam się, co jest gorsze w przypadku siły hasła. Nie masz żadnej polityki dotyczącej haseł lub kiepskiej polityki haseł, jak na obrazku?

Wymienione przez Ciebie wymagania dotyczące siły hasła absolutnie wyrządzają więcej szkody niż pożytku , zwłaszcza maksymalne length.

1. Mogą używać bardzo starej, niezabezpieczonej procedury mieszania. (stąd maksymalna długość)
2. W niektórych obszarach zapewnia to wygodę nad bezpieczeństwem.
   (brak spacji jest pomocna przy przedstawianiu hasła w postaci zwykłego tekstu,
   wielkość liter nie jest rozróżniana, więc istnieją brak połączeń z obsługą wielkich liter)
3. Inne elementy są po prostu głupie.

Szczegółowy opis

Twoje hasło musi:

• Mieć dokładnie osiem znaków

Jedynym przypadkiem, w którym widzę to jako rozsądne rozwiązanie, jest sytuacja, gdy w systemie działa starszy schemat skrótu, który obcina wszystkie oprócz pierwszych 8 znaków.

Na przykład hasła kont użytkowników systemu Solaris 10 domyślnie korzystały z takiego schematu, więc hasła takie jak passwordSup @ rsecur☺ zostały obcięte do hasła !!! Domyślne rozwiązanie dla Solaris 11 nie ma tej wady.

W tym przypadku

1. Programiści powinni pracować nad migracją do lepszej procedury mieszania, która obsługuje długości haseł poza 8.

2. Dopóki taka poprawka nie zostanie wdrożona, maksymalna długość jest rozsądna.

W każdej innej sytuacji , z całą pewnością byłoby głupotą mieć tak krótką długość maksymalną.

• Uwzględnij przynajmniej jedną literę i jedną cyfrę.

• Uwzględnij co najmniej jeden znak specjalny z następującego zestawu: ...

Są one niezbędne, biorąc pod uwagę ich krótką maksymalną długość. Jestem pewien, że rozumiesz potrzebę stosowania takich prymitywnych metod w celu zwiększenia entropii, gdy używane jest krótkie hasło.

• Uwaga: hasło nie rozróżnia wielkości liter.

Chociaż może to być wygodne dla użytkownika (nie martw się o wielkie litery), nigdy nie jest zalecane, ponieważ zawsze zmniejsza entropię hasła. W tym przypadku jest to jeszcze bardziej odradzane ze względu na obecność maksymalnej długości 8 znaków.

Powinno to zostać naprawione ale teraz byłoby to dla nich kłopotliwe, ponieważ istniejący użytkownicy są już przyzwyczajeni do niezabezpieczonej konfiguracji!

Nie zawierają spacji

Jedynym powodem, dla którego to widzę, jest prezentacja hasła w postaci zwykłego tekstu . (np. e-mail z zapomnianym hasłem lub wyszukiwanie pomocy technicznej) Według większości standardów jest to kiepski (niezabezpieczony) projekt oprogramowania.

Lepszą zasadą jest zakazanie wyszukiwania i zezwolenie tylko na jego zmianę. W rzeczywistości zdecydowanie zaleca się stosowanie silnego (powolnego) skrótu hasła, takiego jak BCrypt, który z natury zabrania wyszukiwań w ramach swojego podstawowego projektu.

• Nie zaczynać od ? lub !

Bardzo dziwne, ale nie jest to znaczący zabójca entropii hasła.

• Nie zaczynaj od trzech identycznych znaków

Hej, nie przejmuję się tym za bardzo, ale zastanawiam się, dlaczego patrzą tylko na początek. 3 identyczne / sąsiadujące znaki w dowolnym miejscu 8-znakowego hasła są słabsze niż mogłoby być.

• Hasło musi różnić się od poprzednich 5 haseł.

Prawdopodobnie istnieje dedykowane pytanie Security Stack Exchange na ten temat. Jest to powszechna praktyka w bankowości internetowej i niektórych innych systemach uwierzytelniania.

Zakładam, że jest to również połączone z obowiązkową zaplanowaną zmianą hasła. Prawdopodobne rezultaty to:

• Użytkownicy będą zapisywać swoje hasło zamiast korzystać z pamięci,
• Lub użytkownicy wybiorą prosty wzorzec.

Jeśli jednak zmiana hasła nie jest obowiązkowa, jedynym problemem jest

• Należy nadal przechowywać wartość skrótu nieużywanych haseł w celu porównania ich działania.

i chociaż nie jest to poważny problem, jest źle oceniany.

Zła zasada, taka jak ta, jest gorsza niż żadna.

Ta zasada oznacza, że ​​osoby, które normalnie używają „123”, będą teraz miały nieco bezpieczniejsze hasło, ale nadal jest słabe. Oznacza to również, że ludzie używający czegoś takiego jak „fzFEZ # 5 $ 3rt4564ezezRTyht” (generowane losowo) lub po prostu: „kot skacze po pomalowanej na brązowo ścianie412” (silna entropia), będą teraz miały znacznie słabsze hasło.

osoby używające słabych haseł i tak zostaną zhakowane w tym przypadku (ponieważ ta restrykcyjna i słaba polityka, a atakujący może ustawić określone reguły ataku). Ale ludzie normalnie używający silnych haseł też to zrobią.

Innymi słowy, jest to dużo mniej bezpieczne. Bez jakiejkolwiek polityki, tylko ludzie używający słabych haseł są narażeni; teraz każdy jest bezbronny.

moim zdaniem nie byłoby lepiej. Lista powodów jest następująca:

• Te zasady sprawiają, że ludzie mają tendencję do zapisywania tam haseł i przyklejania ich do monitorów lub w podobny sposób. (jakie zabezpieczenie zapewnia hasło?)
• Reguły te można łatwo wydedukować i (za pomocą tego typu pól) nawet ogłosić potencjalnemu intruzowi. (Na przykład dajmy osobie, której chcemy trzymać z daleka „reguł” dotyczących tego, jakie są nasze hasła, więc muszą zrobić tylko ograniczony zestaw ...)
• Entropia hasła znacznie się poprawia, czyniąc je dłużej. 8 jest w dzisiejszych czasach na tyle trywialne, że atak mógłby wykorzystać urządzenie mobilne do brutalnego wymuszenia hasła.
• reguła mieszania przypadków bez ich sprawdzania sugeruje, że hasło jest zapisywane w postaci zwykłego tekstu (nawet jeśli pamięć jest zaszyfrowana, przez większość czasu klucz szyfrujący jest przechowywany z danymi, co oznacza, że ​​są tam przechowywane w postaci zwykłego tekstu).
• W przypadku większości aplikacji inny schemat pozwoliłby na znacznie większe bezpieczeństwo bez wymagające w ogóle hasła, na przykład:
  • Uwierzytelnianie dwuskładnikowe.
  • Uwierzytelnianie drugiego urządzenia.
  • Uwierzytelnianie za pomocą karty inteligentnej.

Wydaje się, że te zasady zostały przemyślane przez kogoś, kto nie do końca rozumie, jak zagrożenia związane z hasłem wpływają na Twój system. zamiast tego po prostu zaznaczają „wszystkie pola” z jakiegoś powodu.

mówiąc, że może istnieć prawdziwy powód, dla którego to zrobili. Niektóre certyfikaty i zastosowania wymagają wdrożenia niektórych z nich (np. w służbie zdrowia lub w niektórych zastosowaniach rządowych).

Żadna w ogóle nie jest lepsza od pokazanej, szczególnie ze względu na limit 8 znaków.

Wszystkie kombinacje 8 znaków można przetestować w ciągu sekundy z GPU z rodziny Titan i John the Ripper. Chociaż nie wszystkie zasady dotyczące haseł są szkodliwe (minimalna długość jest dobra, jeden + znak specjalny wymusza większy alfabet crack, brak słów ze słownika itp.), Pokazany jest żart, który nie jest zbyt zabawny. Podsumowując, tak, to jest gorsze niż nic, ponieważ nie pozwoli to menedżerom haseł ani inteligentnym użytkownikom chronić się lepiej niż polityka domyślna.

Zasady nigdy nie powinny powstrzymywać dobrych haseł, tylko te okropne.

Co jest gorsze w przypadku siły hasła, złej polityki dotyczącej haseł lub w ogóle jej braku?

To zależy od tego, jaka jest polityka złych haseł.

• „Twoje hasło musi być„ letmein ”” to kiepska polityka dotycząca haseł, która jest zdecydowanie gorsza niż brak jakiejkolwiek polityki, ponieważ uniemożliwia komukolwiek posiadanie dobrego hasła.

• „Twoje hasło musi mieć co najmniej dwa znaki” to kiepska polityka dotycząca haseł, która jest zdecydowanie lepsza niż brak jakichkolwiek zasad, ponieważ umożliwia każdemu użycie dobrego hasła i zapobiega niektórym złym hasłom.

Jest już wiele dobrych odpowiedzi, ale zawsze lubię patrzeć na to z nieco innej perspektywy. Kiedy zastanawiasz się, jak coś wpłynie na próby złamania hasła, musisz przyjrzeć się, jak będą próbować to złamać. Zasadniczo sprowadza się to do dwóch metod. Brutalna siła i „inteligentne” zgadywanie, więc spójrzmy na te dwa.

1) Brutalna siła.

Dokładnie tak to brzmi. Próbują każdego możliwego hasła. Jest to klasyczna próba każdego numeru PIN od 0000 do 9999 na 4-cyfrowym zamku numerycznym. Kluczowymi czynnikami są tutaj liczba możliwych haseł i czas potrzebny na wypróbowanie każdego z nich. Tutaj zasada hasła może być świetna i całkowicie wyeliminować brutalną siłę jako realną opcję ze względu na wymóg 8 cyfr. Może to być również całkowicie katastrofalne, jeśli zostanie użyty wystarczająco słaby hash i może zagwarantować, że każde możliwe hasło zostanie złamane w rozsądnym czasie przez atakującego z wystarczającymi zasobami.

Biorąc pod uwagę zasady w tym przypadku, wydaje się, że zdecydowanie sugeruję coś dość starego na zapleczu, jest całkowicie możliwe, jeśli nie jest prawdopodobne, że hasło jest zaszyfrowane za pomocą czegoś dość słabego, takiego jak MD5 lub SHA1 i prawdopodobnie nie jest solone, a zasady mogą być katastrofalne. Przede wszystkim długość, ale także bez rozróżniania wielkości liter, co zmniejsza liczbę możliwych znaków o ~ 30%. Obecnie mają 26 znaków + 10 cyfr + 28 symboli dla 64 różnych znaków w haśle. Gdyby rozróżniali wielkość liter, mieliby 90 znaków.

Na podstawie kilku szybkich wyszukiwań wydaje się, że gdybyśmy założyli, że atakujący ma rozsądną ilość zasobów i używa jednego z tych słabych skrótów, wydaje się bardzo prawdopodobne, że zasady są rzeczywiście katastrofalne, a jeśli nie są teraz, z pewnością grozi im katastrofa w najbliższej przyszłości, ponieważ moc obliczeniowa zwiększa szybkość łamania. Hasło dłuższe niż 8 znaków może być wymagane do zapewnienia bezpieczeństwa, ale w rzeczywistości na to nie pozwalają.

Czy możliwe jest brutalne wymuszenie wszystkich 8-znakowych haseł podczas ataku offline?

2) „Inteligentne” zgadywanie

W pewnym momencie metoda brutalnej siły staje się niepraktyczna, przetestowanie wszystkich haseł zajęłoby miesiące lub niemożliwe, przetestowanie wszystkich haseł zajęłoby tysiąclecia, a „inteligentne” zgadywanie przejmuje kontrolę. W tym miejscu można zobaczyć ataki słownikowe, dosłowne słowa ze słownika lub listy wcześniej używanych haseł oraz ataki oparte na regułach. Ataki oparte na regułach przejmują słownik i zaczynają dodawać lub zmieniać elementy, aby tworzyć różne odmiany tych haseł. Dodanie liczby i jednego znaku specjalnego na końcu sześcioliterowego słowa w celu uzyskania 8-cyfrowego hasła spełniającego wymagania dotyczące hasła. Tworzenie hasła "leet" poprzez zamianę hasła na p @ ssw0rd, które byłoby poprawnym, ale szybko złamanym hasłem w tym systemie, itp. Te zasady mogą być prawie wszystkim, co możesz wymyślić, co Twoim zdaniem ma sens i stale ewoluuje, gdy uczymy się więcej o tym, jak ludzie zazwyczaj wybierają swoje hasła na podstawie przeszłych wycieków.

Zakładając, że złamanie dotarło do tego punktu, podane przez nich reguły haseł zostałyby włączone do reguł, których użył atakujący do wygenerowania swojego możliwego hasła. Tutaj ich zasady nie są tak katastrofalne, ale nadal prowadziłyby do znacznie mniej ważnych możliwych haseł, więc przyspieszyłyby łamanie. Prawdopodobnie doprowadziłoby to również do powstania pewnych bardzo przewidywalnych haseł z symbolami / liczbami dodanymi na początku / końcu hasła lub w ramach bardzo przewidywalnej zamiany.

Gdyby użytkownicy wybierali hasła losowo, zasady dotyczące haseł pogorszyłyby bezpieczeństwo, ograniczając wybór możliwych haseł, ale użytkownicy nie wybierają haseł losowo. Celem dobrej polityki dotyczącej haseł powinno być skłonienie użytkownika do dokonywania większych wyborów, a tym samym do wybrania silniejszego hasła bez nadmiernego ograniczania przestrzeni na hasła.

Ta polityka ma dobre i złe strony.

mieć dokładnie 8 znaków.

Minimalna długość jest dobra, maksymalna jest zła.

Uwzględnij co najmniej jedną literę i co najmniej jedną cyfrę.

To jest dobre, popycha użytkowników do wyboru zarówno składnika opartego na literach, jak i liczby składnik bazowy.

W haśle nie jest rozróżniana wielkość liter.

Znacznie zmniejsza to rozmiar ustawianego hasła. Z drugiej strony większość ludzi nie używa wielkich liter, chyba że i tak jest wymuszona, a kiedy ich używają, robią to w przewidywalny sposób.

Uwzględnij co najmniej jeden znak specjalny

Znowu dobrze, popycha to twórcę hasła do dokonania innego wyboru.

Zakazane spacje i zasady? i !

Wątpię, czy mają one duże znaczenie.

zabronione powtarzanie się znaków na początku

Prawdopodobnie dobra rzecz, czyli użytkownik nie może po prostu wypełnić hasła powtórzeniami jednej litery.

Ogólnie powiedziałbym, że jeśli masz nieświadomych użytkowników, ta zasada jest prawdopodobnie lepsza niż nic, ale jeśli Twoi użytkownicy mają pojęcie o przyzwoitych hasłach, prawdopodobnie przyniesie więcej szkody niż pożytku.

Mam zamiar pójść inną drogą niż wszystkie dotychczasowe odpowiedzi ... i powiem, że w pewnym momencie to nie ma znaczenia. Algorytm ma o wiele większe znaczenie niż zasady dotyczące haseł.
Na przykład ktoś może użyć ROT13, okropne, tak.
Albo lepiej użyć MD5.
Lub, jeszcze lepiej, SHA-1.
Może wtedy dodadzą sól.
Może użyj crypt ().
Może potem dodadzą pieprz.
Mimo to GPGUP może przepalić miliardy haszów haseł w ciągu sekundy. Więc co jeszcze?
SHA-2-512 ze 128-bitową solą. O wiele lepiej, ale GPGPU potrafi wiele z tych rzeczy.
Zmień na bcrypt. Dużo lepiej. Teraz przechodzimy przez punkt, w którym pojedynczy GPGPU może po prostu spalić je wszystkie szybko.
Zmień na PBKDF2, z pełną solą i pieprzem i 10000 nabojów.
W górę, aby zaszyfrować, a teraz bardzo krótkie hasło to „nie do złamania”, ponieważ algorytm jest tak powolny.

Oto tabela, która może pomóc wyjaśnić to:

  Tries / secNTLM 350,000,000,000 MD5 180,000,000,000 SHA1 63,000,000,000 SHA512Crypt 364,000 Bcrypt 71,000  

Więc kiepskie hasło zaszyfrowane za pomocą bcrypt jest lepsze niż świetne hasło zaszyfrowane za pomocą MD5.

To naprawdę sprowadza się do użytkownika końcowego. Z mojego punktu widzenia, jeśli jako firma / witryna nie ponosisz odpowiedzialności za przejęcie czyjegoś konta, najlepiej zrezygnować z formalnej polityki dotyczącej haseł, przynajmniej restrykcyjnej.

Zawsze byłem zdania, że ​​użytkownik powinien być odpowiedzialny za własne bezpieczeństwo, biorąc pod uwagę, że rozumie konsekwencje takich rzeczy, jak słabe hasła.

To prawda, ta ostatnia część key, tak jakby użytkownik nie wiedział lepiej, powinieneś zmusić go do posiadania bezpieczniejszego hasła niż to, którego chce używać. Jednak zasady dotyczące haseł powinny zachęcać tylko do bezpieczniejszych haseł, a nie ograniczać ich siły, jak ilustruje przykład.

Natknąłem się na to osobiście w witrynie moich uniwersytetów. Moje alfanumeryczne hasło o znacznej długości nie spełniało tam polityki haseł, która zniechęcała do niektórych (ale nie wszystkich: /) znaków specjalnych. Rezultatem było celowo słabsze hasło, ponieważ dla mnie trudniej było zapamiętać hasło, którego celowo nie zapamiętałem.

Szczególnie w tym przypadku podejrzewam, że „polityka haseł” była bardziej wymówką, aby uniknąć parsowania ciągów / oczyszczania w zapleczu niż uzasadnionym sposobem zachęcania do większego bezpieczeństwa.

Wreszcie zasady dotyczące haseł, jeśli są wdrażane, powinny zmieniać się z czasem. Oznacza to, że to, co mogło być uważane za bezpieczne hasło w latach 90., nie jest już takie w 2016 r., Kiedy przeciętny konsument może wykorzystać przetwarzanie w chmurze lub klastry GPU, aby rzucić ogromną i stale rosnącą moc komputera na swoje hasła.