Czy powinienem narzucić maksymalną długość haseł?

Rozumiem, że narzucanie minimalnej długości haseł ma wiele sensu (aby uchronić użytkowników przed sobą), ale mój bank wymaga, aby hasła miały od 6 do 8 znaków i zacząłem się zastanawiać ...

• Czy to nie ułatwiłoby ataków siłowych? (Zły)
• Czy to oznacza, że ​​moje hasło jest przechowywane w postaci niezaszyfrowanej? (Zły)

Jeśli ktoś z (miejmy nadzieję), że pracuje dla niego kilku dobrych specjalistów ds. Bezpieczeństwa IT, narzuca maksymalną długość hasła, czy powinienem pomyśleć o zrobieniu czegoś podobnego? Jakie są wady / zalety tego?

Hasła są haszowane do 32, 40, 128, dowolnej długości. Jedynym powodem minimalnej długości jest zapobieganie łatwym do odgadnięcia hasłom. Nie ma celu dla maksymalnej długości.

Obowiązkowe XKCD wyjaśniające, dlaczego wyrządzasz użytkownikowi krzywdę, jeśli narzucisz maksymalną długość:

Maksymalną długość określoną w polu hasła należy odczytywać jako OSTRZEŻENIE BEZPIECZEŃSTWA . Każdy rozsądny, świadomy bezpieczeństwa użytkownik musi założyć najgorsze i oczekiwać, że ta witryna będzie przechowywać Twoje hasło dosłownie (tj. Bez zaszyfrowania, jak wyjaśnił epochwolf).

W takim przypadku:

1. Jeśli to możliwe, unikaj używania tej strony jako zarazy. Najwyraźniej nic nie wiedzą o bezpieczeństwie.
2. Jeśli naprawdę musisz korzystać z tej witryny, upewnij się, że Twoje hasło jest niepowtarzalne - w przeciwieństwie do hasła, którego używasz gdzie indziej.

Jeśli tworzysz witrynę, która akceptuje hasła, nie ustalaj głupiego limitu haseł, chyba że chcesz zostać tarowany tym samym pędzlem.

[Wewnętrznie, oczywiście, twój kod może traktować tylko pierwsze 256/1024 / 2k / 4k / (cokolwiek) bajtów jako „znaczące”, aby uniknąć łamania gigantycznych haseł.]

Zezwolenie na całkowicie nieograniczoną długość hasła ma jedną poważną wadę, jeśli akceptujesz hasło z niezaufanych źródeł.

Nadawca może próbować podać Ci tak długie hasło, że spowoduje to odmowę usługi dla innych osób. Na przykład, jeśli hasło to 1 GB danych i spędzasz cały swój czas, zaakceptuj je, dopóki nie zabraknie pamięci. Teraz przypuśćmy, że ta osoba wysyła Ci to hasło tyle razy, ile chcesz zaakceptować. Jeśli nie jesteś ostrożny z innymi powiązanymi parametrami, może to doprowadzić do ataku DoS.

Ustawienie górnej granicy na około 256 znaków wydaje się zbyt hojne według dzisiejszych standardów.

Po pierwsze, nie zakładaj, że banki zatrudniają dobrych specjalistów ds. Bezpieczeństwa IT. Wiele nie .

To powiedziawszy, maksymalna długość hasła jest bezwartościowa. Często wymaga od użytkowników stworzenia nowego hasła (argumenty dotyczące wartości używania różnych haseł w każdej witrynie na bok), co zwiększa prawdopodobieństwo, że po prostu je zapiszą. Zwiększa to również znacznie podatność na ataki dowolnym wektorem, od brutalnej siły po socjotechnikę.

Ustawianie maksymalnej długości hasła mniejszej niż 128 znaków jest teraz odradzane przez ściągawkę OWASP Authentication Cheat Sheet

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

Cytując cały akapit:

Dłuższe hasła zapewniają większą kombinację znaków, a tym samym utrudniają atakującemu ich odgadnięcie.

Minimalna długość haseł powinna być wymuszona przez aplikację. Hasła krótsze niż 10 znaków są uważane za słabe ([1]). Chociaż wymuszanie minimalnej długości może powodować problemy z zapamiętywaniem haseł wśród niektórych użytkowników, aplikacje powinny zachęcać ich do ustawiania haseł (zdań lub kombinacji słów), które mogą być znacznie dłuższe niż typowe hasła, a jednocześnie znacznie łatwiejsze do zapamiętania.

Maksymalna długość hasła nie powinna być zbyt mała, ponieważ uniemożliwi to użytkownikom tworzenie haseł. Typowa maksymalna długość to 128 znaków. Hasła krótsze niż 20 znaków są zwykle uważane za słabe, jeśli składają się tylko z małych liter łacińskich. Każdy znak się liczy !!

Upewnij się, że każdy znak wpisany przez użytkownika jest faktycznie zawarty w haśle. Widzieliśmy systemy, które skracały hasło na długość krótszą niż podana przez użytkownika (np. Obcięte do 15 znaków po wprowadzeniu 20). Jest to zwykle obsługiwane przez ustawienie długości WSZYSTKICH pól wprowadzania hasła na dokładnie taką samą długość, jak maksymalna długość hasła. Jest to szczególnie ważne, jeśli maksymalna długość hasła jest krótka, na przykład 20-30 znaków.

Jednym z powodów, dla których mogę sobie wyobrazić wymuszanie maksymalnej długości hasła, jest to, że frontend musi łączyć się z wieloma starszymi zapleczami systemowymi, z których jeden sam wymusza maksymalną długość hasła.

Innym sposobem myślenia może być to, że jeśli użytkownik jest zmuszony do używania krótkiego hasła, jest bardziej prawdopodobne, że wymyśli przypadkowy bełkot niż łatwe do odgadnięcia (przez znajomych / rodzinę) slogan lub pseudonim. To podejście jest oczywiście skuteczne tylko wtedy, gdy frontend wymusza mieszanie cyfr / liter i odrzuca hasła, które mają jakiekolwiek słowa ze słownika, w tym słowa napisane w l33t-speak.

Jednym z potencjalnie ważnych powodów, aby narzucić maksymalną długość hasła, jest to, że proces jego haszowania (z powodu użycia powolnej funkcji haszującej, takiej jak bcrypt) zajmuje zbyt dużo czasu; coś, co mogłoby zostać wykorzystane w celu wykonania ataku DOS na serwer.

Z drugiej strony serwery powinny być skonfigurowane tak, aby automatycznie odrzucały programy obsługi żądań, które trwają zbyt długo. Więc wątpię, żeby to był duży problem.

Myślę, że masz rację w obu punktach. Jeśli przechowują haszowane hasła, tak jak powinni, długość hasła nie wpływa w żaden sposób na ich schemat bazy danych. Posiadanie otwartego hasła powoduje dodanie jeszcze jednej zmiennej, którą atakujący siłą musi uwzględnić.

Trudno znaleźć wymówkę dla ograniczenia długości hasła, poza złym projektem.

Jedyną korzyścią, jaką widzę przy maksymalnej długości hasła, byłoby wyeliminowanie ryzyka ataku polegającego na przepełnieniu bufora spowodowanego zbyt długim hasłem, ale istnieją znacznie lepsze sposoby radzenia sobie z taką sytuacją.

Zignoruj ​​osoby, które mówią, że nie wolno sprawdzać długich haseł. Owasp dosłownie mówi, że 128 znaków powinno wystarczyć. Aby dać wystarczająco dużo miejsca na oddech, możesz dać trochę więcej, powiedzmy 300, 250, 500, jeśli masz na to ochotę.

https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length

Długość hasła Dłuższe hasła zapewniają większą kombinację znaków, przez co utrudniają atakującemu ich odgadnięcie.

...

Maksymalna długość hasła nie powinna być zbyt mała, ponieważ uniemożliwi to użytkownikom tworzenie haseł. Typowa maksymalna długość to 128 znaków . Hasła krótsze niż 20 znaków są zwykle uważane za słabe, jeśli składają się tylko z małych liter łacińskich.

Przechowywanie jest tanie, więc ogranicz długość hasła. Nawet jeśli szyfrujesz hasło, a nie tylko haszowanie, 64-znakowy ciąg nie zajmie dużo więcej niż 6-znakowy ciąg do zaszyfrowania.

Jest szansa, że ​​system bankowy nakłada się na starszy system, więc był w stanie zapewnić tylko określoną ilość miejsca na hasło.

Mój bank też to robi. Kiedyś zezwalało na dowolne hasło, a ja miałem 20-znakowe. Pewnego dnia zmieniłem to i oto dało mi to maksymalnie 8 i wyciąłem niealfanumeryczne znaki, które były w moim starym haśle. Nie miało to dla mnie żadnego sensu.

Wszystkie systemy zaplecza w banku działały wcześniej, kiedy używałem mojego 20-znakowego hasła bez znaków alfanumerycznych, więc starsze wsparcie nie mogło być powodem. A nawet gdyby tak było, powinny nadal umożliwiać posiadanie dowolnych haseł, a następnie tworzyć skrót, który pasuje do wymagań starszych systemów. Co więcej, powinni naprawić starsze systemy.

Rozwiązanie karty inteligentnej nie pasowałoby do mnie. Mam już za dużo kart i tak jest ... Nie potrzebuję kolejnej sztuczki.

Jeśli akceptujesz hasło o dowolnej wielkości, zakłada się, że jest ono skracane do długości kurtyny ze względów wydajnościowych, zanim zostanie zaszyfrowane. Problem z obcinaniem polega na tym, że wraz ze wzrostem wydajności serwera w czasie nie można łatwo zwiększyć długości przed obcięciem, ponieważ jego skrót byłby wyraźnie inny. Oczywiście możesz mieć okres przejściowy, w którym obie długości są mieszane i sprawdzane, ale zużywa to więcej zasobów.

Staraj się nie nakładać żadnych ograniczeń, chyba że jest to konieczne. Uwaga: może i będzie konieczne w wielu różnych przypadkach. Radzenie sobie ze starszymi systemami jest jednym z tych powodów. Upewnij się, że dobrze przetestowałeś przypadek bardzo długich haseł (czy twój system poradzi sobie z hasłami o długości 10 MB?). Możesz napotkać problemy typu Denial of Service (DoS), ponieważ funkcje Key Defivation Functions (KDF), z których będziesz korzystać (zwykle PBKDF2, bcrypt, scrypt) zajmą zbyt dużo czasu i zasobów. Przykład z życia: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

Czy powinna być maksymalna długość? Jest to ciekawy temat w IT, ponieważ dłuższe hasła są zwykle trudniejsze do zapamiętania, a przez to bardziej prawdopodobne, że zostaną zapisane (DUŻO nie-nie z oczywistych powodów). Dłuższe hasła są również częściej zapominane, co niekoniecznie stanowi zagrożenie dla bezpieczeństwa, ale może prowadzić do problemów administracyjnych, utraty produktywności itp. Administratorzy, którzy uważają, że te problemy są naglące, prawdopodobnie narzucą maksymalne długości hasłom.

Osobiście wierzę w tę konkretną kwestię, dla każdego użytkownika własnego. Jeśli myślisz, że pamiętasz 40-znakowe hasło, tym więcej mocy masz!

To powiedziawszy, hasła szybko stają się przestarzałym sposobem bezpieczeństwa, karty inteligentne i uwierzytelnianie certyfikatów okazują się bardzo trudne lub niemożliwe do brutalnej siły, jak stwierdziłeś, jest to problem, a na serwerze musi być przechowywany tylko klucz publiczny z prywatnym klucz do karty / komputera przez cały czas.

Dłuższe hasła lub frazy hasła są trudniejsze do złamania po prostu na podstawie długości i łatwiejsze do zapamiętania niż wymaganie złożonego hasła.

Prawdopodobnie najlepiej wybrać dość długą (10+) minimalną długość, ograniczając długość bezużyteczną.

Starsze systemy (już wspomniane) lub łączenie się z systemami innych dostawców mogą wymagać ograniczenia liczby 8 znaków. Może to być również nieudana próba uratowania użytkowników przed sobą. Ograniczenie go w ten sposób spowoduje zbyt wiele haseł pssw0rd1, pssw0rd2 itp. W systemie.

Jednym z powodów, dla których hasła mogą nie być szyfrowane, jest używany algorytm uwierzytelniania. Na przykład niektóre algorytmy skrótu wymagają na serwerze wersji hasła w postaci zwykłego tekstu, ponieważ mechanizm uwierzytelniania obejmuje zarówno klienta, jak i serwer, wykonujące te same obliczenia matematyczne na wprowadzonym haśle (które generalnie nie generuje tego samego wyniku za każdym razem jak hasło jest łączona z losowo generowanym „nonce”, który jest współdzielony między dwiema maszynami).

Często można to wzmocnić, ponieważ w niektórych przypadkach podsumowanie można częściowo obliczyć, ale nie zawsze. Lepszą drogą jest przechowywanie hasła z odwracalnym szyfrowaniem - oznacza to, że źródła aplikacji muszą być chronione, ponieważ będą zawierać klucz szyfrowania.

Digst auth umożliwia uwierzytelnianie na kanałach nieszyfrowanych. Jeśli używasz SSL lub innego szyfrowania pełnokanałowego, nie ma potrzeby używania mechanizmów uwierzytelniania skrótu, co oznacza, że ​​zamiast tego hasła mogą być przechowywane w postaci zaszyfrowanej (ponieważ hasła mogą być bezpiecznie przesyłane zwykłym tekstem przez sieć (dla określonej wartości sejfu).

Tylko hasło o długości 8 znaków brzmi po prostu źle. Jeśli powinien istnieć limit, to co najmniej 20 znaków jest lepszym pomysłem.

Myślę, że jedynym limitem, który powinien być zastosowany, jest limit 2000 liter lub coś innego niewiarygodnie wysokiego, ale tylko w celu ograniczenia rozmiaru bazy danych, jeśli jest to problem