Weź pięć szympansów. Umieść je w dużej klatce. Zawieś banany na dachu klatki. Zapewnij szympansom drabinę. ALE dodaj także do bananów czujnik zbliżeniowy, aby gdy szympans zbliżył się do banana, uruchomione zostały węże wodne, a cała klatka była dokładnie przemoczona.

Wkrótce szympansy dowiedzą się, że banany i drabina najlepiej ignorować.

Teraz usuń jednego szympansa i zastąp go nowym. Ten szympans nic nie wie o wężach. Widzi banana, zauważa drabinę, a ponieważ jest mądrym naczelnym, wyobraża sobie, że nadepnie po drabinie, aby dosięgnąć bananów. Następnie zręcznie chwyta drabinę ... a cztery inne szympansy rzucają się na niego i biją go prosto. Wkrótce uczy się ignorować drabinę.

Następnie usuń kolejnego szympansa i zastąp go nowym. Scenariusz pojawia się ponownie; kiedy chwyta drabinę, zostaje poturbowany przez cztery szympansy - tak, łącznie z poprzednim „świeżym” szympansem. Zintegrował pojęcie „nie będziesz dotykać drabiny”.

Powtarzaj. Po kilku operacjach masz pięć szympansów, które są gotowe uderzyć każdego szympansa, który odważyłby się dotknąć drabiny - i żaden z nich nie wie dlaczego.

Początkowo jakiś programista gdzieś pracował w starym systemie uniksowym z poprzedniego wieku, który używał starej „krypty” opartej na DES, w rzeczywistości funkcji haszującej hasła pochodzącej z szyfru blokowego DES. W tej funkcji haszującej używa się tylko pierwszych ośmiu znaków hasła (i tylko 7 młodszych bitów każdego znaku). Kolejne znaki są ignorowane. To banan.

Internet jest pełen szympansów.

Te ograniczenia są często wprowadzane z różnych powodów:

• Interakcja ze starszymi systemami, które nie obsługują długich haseł.
• Konwencja (tj. „zawsze zrobiłem to w ten sposób ”)
• Prosta naiwność lub ignorancja.

Jeśli chodzi o bezpieczeństwo, nie ma potrzeby ograniczania długości hasła. I tak powinny być zaszyfrowane przy użyciu KDF, takiego jak bcrypt. Aby poprawić wydajność, warto ustawić bardzo duży limit (np. 512 znaków) na długość hasła, aby nikt nie wysłał Ci hasła o rozmiarze 1 MB i nie wykonał zadania serwera przez 10 sekund podczas obliczania skrótu.

1. Jeśli przechowują go w postaci zwykłego tekstu lub zaszyfrowanego tekstu jawnego, to prawdopodobnie jest to maksymalna wartość, jaką można przechowywać w bazie danych. Z drugiej strony należy jak najdalej od tych witryn.
2. Aby uniknąć ataków DOS. Dzieje się tak zwykle wtedy, gdy mają one bardzo wysoki limit, np. 512 lub 1024 bajtów.
3. Aby zachować zgodność z przepisami, które są faktycznie tworzone przez ludzi, którzy nie wiedzą nic o bezpieczeństwie IT.
4. Z powodów starszych, jak wskazał Tom Leek

Przy okazji. oto (historyczna) lista witryn o wysokim rankingu, które mają maksymalne długości haseł:

http://web.archive.org/web/20130907182806/https://defuse.ca/password- policy-hall-of-shame.htm

Zadałem to pytanie na Bol.com, jednym z największych sklepów internetowych w Holandii. Ich odpowiedzią było zapobieżenie zalewaniu e-mailami pomocy technicznej o zapomnianych hasłach. Następnie z zaciekawieniem zignorowali moje zapytanie dotyczące funkcji resetowania hasła, które po prostu wysyła ci e-mail z linkiem resetowania, gdy zapomniałeś hasła.

Doszedłem do wniosku, że najprawdopodobniej jest to decyzja zespołu zarządzającego. Alternatywnie może być tak, że nie haszują haseł i używają tego, aby zapobiec zalaniu bazy danych (nawet jeśli możesz mieć dłuższą nazwę użytkownika, więc wydaje się to mało prawdopodobne). Nie odpowiedzieli też na pytanie, czy haszują hasła (można by pomyśleć, że jeśli wszystko jest w porządku, nie byłoby powodu, aby nie odpowiadać).

Chciałbym zacytować próbę ograniczenia problemów związanych z obsługą klienta.

Im większe i bardziej złożone hasła, tym większe prawdopodobieństwo, że klient wprowadzi nieprawidłowe hasło, zostanie zablokowany, a następnie skontaktuje się z obsługą klienta, zajmując czas tej osoby.

To niesamowite, jak wiele osób nie jest w stanie dokładnie wpisać normalnego, słabego hasła, nie mówiąc już o haśle, które jest o kilka znaków dłuższe lub musiało mieć dodatkowy znak lub 2 wprowadzone ze względu na złożoność.

Być może OT, ale długie hasła niekoniecznie są gwarantowanym prawdziwym środkiem bezpieczeństwa, ponieważ w dzisiejszych czasach hasła są wprost kradzione na dość powszechnej podstawie.

Nieudane próby logowania i śledzenie odległości geograficznej od normalnego użycia logowania to znacznie dokładniejsze wskaźniki. jeśli adres IP należący do kraju o znanym profilu hakerskim / ataku loguje się do amerykańskiego banku i ten login nigdy nie był używany z tej lokalizacji .....

Wiele znanych miejsc, takich jak SF / banki generalnie mają bardzo małą liczbę nieudanych prób logowania, co skutkuje blokadami całego systemu. Niektóre, takie jak SF, posuwają się nawet do przydzielania indywidualnych adresów IP, co oznacza, że ​​nie można zalogować się z nowego adresu IP bez autoryzacji.

„Interakcja ze starszymi systemami, które nie obsługują długich haseł”. jak wspomniano powyżej, jest to powód, dla którego jedna firma, w której pracowałem, wymusiła maksymalną długość hasła.

W ramach odmiany „grupa porusza się tak szybko, jak jej najwolniejszy członek”, stosowanie wielu systemów użytkownicy musieli mieć dostęp do korzystania z tych samych danych logowania, co oznaczało, że wszelkie ograniczenia jednego z tych systemów musiałyby zostać zastosowane do wszystkich kont.

Więc jeśli jedna aplikacja nie Jeśli nie ^, to wszystkie hasła do wszystkich systemów nie mogą mieć znaku ^. Jeśli jeden program nie lubił haseł> 8 znaków, wszystkie konta musiały mieć hasła < 9 znaków. Tak więc w złożonym środowisku, takim jak BigCo, w którym pracowałem, może to obejmować kilkanaście lub dwa tuziny różnych programów; LCD był tym, co każdy dostał.

Używali też IE6.

Inną możliwością, którą chciałbym się zająć, jest to, że hasła są czasami ograniczone przez długość pola używanego do ich zapisania, gdy są zapisywane jako zwykły tekst. Jeśli twoim polem jest VARCHAR (32), możesz zapisać maksymalnie 32 znaki.

Jednak oznacza to coś jeszcze gorszego - że hasło jest zapisywane w postaci zwykłego tekstu. Dlatego właśnie akceptujemy tego rodzaju przestępstwa jako (nieistotne) dowody na stronie plaintextoffenders.com.

Limit długości hasła jest rozsądny, o ile ten limit nadal pozwala na stosowanie silnych haseł; np. limit nie jest mniejszy niż 64 znaki. Głośny limit podczas ustawiania hasła jest znacznie lepszy niż ciche obcinanie hasła.

Jeśli aplikacja ostatecznie przechowuje hasło z 128-bitowym hashem (miejmy nadzieję, że zaszyfrowane i rozciągnięte na klucz), nie ma korzyści z dłuższego zezwalania na hasła niż ~ 64 znaków. Np. W przypadku hasła diceware z 5 znakowymi słowami i spacjami między nimi, 64-znakowe hasło pozwala na 10 słów, które miałyby entropię większą niż 128 bitów.

Deweloper może potencjalnie martwić się wstrzyknięciem SQL lub ataki z przepełnieniem bufora wstrzykiwane przez pole hasła - oczywiście, aby zapobiec tym atakom, należy użyć standardowych metod: zawsze używaj parametrów związanych z SQL (w przeciwieństwie do manipulacji na ciągach znaków do konstruowania zapytań) i zawsze poprawnie ograniczaj sprawdzaj ciągi znaków (prawdopodobnie za pomocą bezpiecznego programowania języki lub bezpieczne biblioteki z wbudowanymi zabezpieczeniami). Musisz się martwić tymi atakami na wszystkie dane wejściowe użytkownika; nie jest to unikalne dla pola hasła, więc ochrona uzyskana przez maksymalny rozmiar hasła jest prawdopodobnie pomijalna.

Mogą istnieć również styczne przyczyny ograniczeń. Bank, który wydaje użytkownikom karty bankomatowe z kodem PIN (osobisty numer identyfikacyjny), może zmusić użytkowników do korzystania z kodów PIN o długości od 4 do 10 cyfr. Zezwolenie użytkownikowi na ustawienie i używanie 50-cyfrowego kodu PIN prawdopodobnie przyniosłoby w praktyce niewielki wzrost bezpieczeństwa w porównaniu z 8-cyfrowym kodem PIN - gdy atakujący potrzebuje zarówno karty bankomatowej użytkownika (która nie została wywołana jako skradziona), należy użyć monitorowanego Bankomat i zostaje zablokowany po 4 błędnych próbach. 50-cyfrowy kod PIN może być droższy pod względem kosztów ludzkich dla Twojego banku, ponieważ byłby on częściej zapomniany / wprowadzany nieprawidłowo - może skłonić pracownika do zbadania sprawy (np. Sprawdzenia wideo z bankomatu i porównania z poprzednimi udanymi transakcjami) lub pracownik przeprowadza klienta przez koniecznie długi mechanizm resetowania hasła (np. mechanizm resetowania musi być kosztowny, aby nie był najsłabszym ogniwem). Cały ten proces może prowadzić do złej jakości obsługi klienta, której bank chce uniknąć.

Jak już inni zauważyli, głównym powodem, dla którego pojawia się 8 lub mniej znaków, jest radzenie sobie ze starszymi systemami, które nie obsługują niczego dłuższego.

Następnie jest ogólnie dobry pomysł wyznaczanie górnej granicy tego, co jest rozsądne. Powiedzmy, że jest to 500 znaków. Nie byłoby nierozsądne sądzić, że ktoś, kto poda hasło dłuższe niż 500 znaków, może nie być dobry.

Ale nawet jeśli używasz obecnie zalecanego systemu haszowania haseł, nadal istnieją ograniczenia. Bcrypt, który jest szeroko stosowany iz tego, co mogę powiedzieć, ogólnie uważany za dobrą / silną opcję haszowania haseł, obsługuje tylko pierwsze 72 znaki. Wszystko, co przekracza 72 znaki, zostaje wyrzucone. Jeśli moje hasło ma 100 znaków, a twoje 150, jeśli zaczyna się tymi samymi 72 znakami, bcrypt uzna je za takie same.

Biorąc pod uwagę ten konkretny limit w bcrypt, jeśli używasz bcrypt, możesz chcieć wymuszaj limit 72 znaków, aby upewnić się, że wszystkie unikalne hasła są faktycznie uznawane za unikalne przez Twój system uwierzytelniania.

Wiele witryn uważa, że ​​długie hasło nie jest potrzebne, ponieważ istnieje ochrona typu brute force (np. ograniczenie liczby prób logowania na adres IP), która nie ma większego znaczenia między długimi a krótkimi hasłami. W obu przypadkach zajęłoby to lat, aby wypróbować wszystkie możliwe kombinacje.

Jedynym zaleceniem byłoby użycie losowych znaków (! @ # $% ^ & * -_ = + / \ '") długich z AZ 0-9.

Kolejnym powodem jest projekt interfejsu użytkownika i ogólne wrażenia użytkownika: dla wielu użytkowników nie jest oczywiste, co się dzieje, gdy widoczna długość pola wejściowego zostaje osiągnięta, gdy każdy znak jest wyświetlany jako gwiazda lub duża kropka. Może to zmylić użytkowników i wywołać negatywne emocje (mniejsze prawdopodobieństwo, że coś kupią, wrócą lub polecą witrynę znajomemu). Możliwe są rozwiązania techniczne, ale po prostu łatwiej jest ograniczyć długość, np. do 20 znaków, aby kursor nigdy nie doszedł do końca pola wprowadzania.

Powiedziałbym, że są trzy główne powody:

1. Starsze systemy nie obsługujące znaków specjalnych
2. Pragnienie obniżenia narzutu wsparcia i korzystania z systemu poprzez faktyczne zapamiętanie haseł użytkowników. Innymi słowy, jeśli pozwolisz użytkownikom tworzyć i używać haseł, których nie pamiętają, to zrobią to, w wyniku czego albo cię tym zdenerwują, albo przestaną korzystać z witryny z powodu kłopotów
3. Programiści nie chcąc martwić się parsowaniem znaków specjalnych pochodzących od niezaufanych użytkowników, co może być potencjalnie niebezpieczne

W przeszłości głównym powodem był prawdopodobnie brak zdolności do obsługiwać hasła (nr 1), a dziś jest to prawdopodobnie brak chęci ich obsługi - głównie od nr 2, ale częściowo od nr 3.

Z dodatkowymi ograniczeniami (ogólnie akceptowane są tylko liczby), może być również motywowane faktem, że umożliwia (lub może zezwalać, jeśli zajdzie taka potrzeba) na wprowadzenie hasła przez jakiś interfejs o ograniczonej pojemności ... / p>

Właśnie dlatego wiele banków ustanowiło takie ograniczenia dla haseł dostępu do sieci, aby umożliwić dostęp przez starsze systemy, które mają tylko klawiatury numeryczne (bankomaty, telefony ...)

Wszystkie znane mi witryny banków mają system podobny do kodu PIN, który blokuje Twoje konto po 3 nieudanych próbach podania hasła. Oznacza to, że długie hasła przyniosłyby skutki odwrotne do zamierzonych, ponieważ łatwiej je pomylić lub zapomnieć, zwłaszcza, że ​​ich nie widać (a gdybyś je widział, bezpieczeństwo byłoby jeszcze gorsze).

Jeśli weźmiesz np. . system pinów dla smartfonów, w którym wpisujesz 4 cyfry, szanse na odgadnięcie go w ciągu 3 prób wynoszą 0,03%. Przy 8 cyfrach szanse na prawidłowe odgadnięcie (jeśli sekwencja jest generowana losowo i nie jest wybierana głupio) stają się tak małe, że gdybyś spróbował odgadnąć hasła 7 miliardów ludzi, zgadłbyś tylko średnio tylko 209 haseł poprawnie. Jeśli dozwolone są znaki i / lub znaki specjalne, szanse na zgadnięcie będą jeszcze mniejsze, pomnożone odpowiednio przez współczynnik 1 ^ -4 lub 1 ^ -6.

Nawet jeśli użytkownicy mogą wybierać hasła i wybierz je w sposób pół-predykcyjny, w ciągu 3 prób nie da się złamać żadnego konkretnego konta, a Twoja średnia nie poprawiłaby się zbytnio, nawet gdybyś miał dużo danych, jak wszystkie urodziny w rodzinie i imiona wszystkich w rodzinie i każdym przyjacielu danej osoby. Jest mało prawdopodobne, że będziesz mieć wiarygodną i wyczerpującą listę tego rodzaju dla dużej populacji.