... które mogą być przydatne w ataku, ale zwykle nie są dostępne dla atakującego

Znajomość nieprawidłowych znaków wejściowych jest przydatna, ale atakujący może je łatwo znaleźć wystarczy kilka prób. Dlatego te informacje nie są tak naprawdę tajne, a nieświadomość wszystkim użytkownikom, co poszło nie tak, w rzeczywistości nie odstrasza napastników, a jedynie odstrasza niewinnych użytkowników, ponieważ nie mogą kontynuować.

Stworzenie użytkownikom frustrującej psychicznie sytuacji może skłonić ich do podejmowania mniej bezpiecznych decyzji. Na przykład, próbują napisać hasło po szwedzku, ale wprowadzone dane odrzucają znak å bez wyjaśnienia. Zamiast wybierać inne dobre hasło bez å , rzucają ręce i używają password123 - takiego, które łatwo pokonać atakiem słownikowym.

W ten sposób , próbowałeś stworzyć „bezpieczniejszy” system poprzez zaciemnienie, ale kiedy weźmiemy pod uwagę zachowania użytkowników, jest on w rzeczywistości mniej bezpieczny.

Ostatecznie prawidłowe znaki można wykryć za pomocą systematycznych środków. Ukrywanie ich nie jest warte szkód, jakie możesz wyrządzić zachowaniom użytkowników.

Więcej informacji można znaleźć w artykułach „ Bezpieczeństwo i uprzedzenia poznawcze: badanie roli umysłu” i „ Pomiar wpływu polityki haseł na bezpieczeństwo przy użyciu funkcji poznawczo-behawioralnych Modelowanie oparte na agentach ”autorstwa Seana Smitha i wsp.

To zależy.

Jeśli komunikat opisuje błąd z punktu widzenia zwykłego użytkownika, np. „Trzeci znak musi być cyfrą”, nie jest to luka w zabezpieczeniach. Jednak wyświetlenie wyrażenia regularnego używanego do walidacji oznacza ujawnienie szczegółów implementacji , które mogą być słabością, np. niektóre biblioteki intensywnie używają wywołań rekurencyjnych, a niektóre wyrażenia mogą powodować przepełnienie stosu lub duże zużycie pamięci i procesora, co może prowadzić do DoS.

CWE-200 definiuje ujawnianie informacji jako słabość tylko wtedy, gdy użytkownik nie ma wyraźnego upoważnienia do dostępu do tych informacji . Rozważasz wejście użytkownika. Oznacza to, że użytkownik pozwala wprowadzić te informacje, a tym samym może zobaczyć te informacje i oczywiście może zobaczyć wszelkie komunikaty o błędach walidacji związane z tym wejściem.

inne komunikaty techniczne mogą zawierać informacje o technologiach zastosowanych w aplikacji (np. jaka wersja jakich bibliotek są używane), o środowisku (np. układ katalogu i uprawnienia, typ i wersja systemu operacyjnego) itp. Atakujący może wykorzystać te informacje do skutecznego wybieraj exploity dla tych konkretnych technologii, bibliotek, systemu operacyjnego itp. Dlatego ujawnienie takich informacji użytkownikowi jest potencjalnie słabym punktem.

Brak wyjaśnienia użytkownikowi, co jest nie tak w jego danych wejściowych, to zdecydowanie zły UX, ale nie bezpieczeństwo poprawa.

Nie myl tego z podobnymi przypadkami, gdy dane są poufne i każda związana z nimi walidacja może być poufna. Na przykład, jeśli użytkownik wprowadził litery w polu, w którym spodziewasz się roku, wyjaśnienie tego błędu użytkownikowi jest bezpieczne. Jeśli jednak użytkownik poda adres e-mail, a Ty sprawdzisz, czy jest on zarejestrowany w Twoim systemie, to każda informacja (adres jest znany, adres nieznany) może być słabym punktem. Dlatego jeśli zamierzasz wdrożyć komunikaty walidacyjne lub inne informacje zwrotne dotyczące danych wejściowych użytkownika, oceń konsekwencje. Ale domyślny zakaz przesyłania opinii dla wszystkich pól może być słabym UX z fałszywym poczuciem bezpieczeństwa.

To tylko jeden z wielu scenariuszy, w których oczekuje się kompromisów między bezpieczeństwem a użytecznością systemu.

Istnieje jednak ogromna różnica między wyświetlaniem śladów stosu (słaba obsługa błędów) a zrzeczenie się, które znaki są oczekiwane lub zabronione w polu wejściowym.

W większości scenariuszy można argumentować, że zrzeczenie się, które znaki są oczekiwane lub zabronione w polu wejściowym, nie jest luką w zabezpieczeniach w ogóle, jeśli istnieją inne mechanizmy bezpieczeństwa, takie jak ograniczanie prób podania hasła.

Na podstawie modelu modelowania zagrożeń można stwierdzić, że jest to akceptowane ryzyko systemowe.

Niewidzialność to nie bezpieczeństwo. Dobry system jest bezpieczny nawet wtedy, gdy atakujący wie o nim wszystko. W twoim przypadku zredukowanie zmarnowanych przypuszczeń dotyczących pęknięć o pewien procent, powiedzmy 25%, nie powinno osłabić praktyczności pękania: 1 bilion lat jest tak samo praktyczny jak 0,75 biliona lat. Niezamknięte szczegóły implementacji pomagają również nowym dobrym ludziom w obronie.

Są też kwestie społeczne. Znak „UWAŻAJ NA DOG” może spowodować ujawnienie szczegółów implementacji zabezpieczeń, ale także zniechęca do przeprowadzania pewnej skali typowych ataków. Pies pomaga, znany lub nieznany, ale znak może obniżyć koszty utrzymania ogrodzenia, co uwalnia zasoby do toczenia innych bitew.

Inne odpowiedzi pokazują, że ujawnienie tego nie jest kwestią bezpieczeństwa.

Będę spierał się z prawdziwą anegdotą, że nieujawnianie może prowadzić nie tylko do frustracji użytkowników, ale nawet do obniżenia bezpieczeństwa.

Zdarzyło mi się to więcej niż raz w witrynach, w których nie było jasne, jakie znaki są dozwolone. W tamtym czasie nie korzystałem z generatora haseł, więc miałem mentalny schemat zapamiętywania haseł. Wymagało to użycia kilku znaków specjalnych, takich jak $ @. & . Kilka sfrustrowanych prób, w których otrzymałem tylko „nieprawidłowe znaki w haśle” i stopniowo zacząłem eliminować znaki specjalne. Potem pojawiło się „Twoje hasło nie jest wystarczająco bezpieczne, spróbuj dodać kilka cyfr i symboli” ... tak ... w tym momencie jestem zdecydowanie zrelaksowany.

W końcu udało mi się zaakceptować moje hasło. Który nie tylko zawierał tylko jeden znak specjalny, ale także nie pasował do żadnego z moich schematów zapamiętywania haseł, więc musiałem ... hmm ... przechowywać go gdzie indziej (to było zanim jeszcze wiedziałem o menedżerach haseł, więc pozwolę wyobrażasz sobie, jak go zabezpieczyłem. Powiem ci, że był jak helikopter i jak sznurek).

Nie widzę problemu w ujawnieniu zestawu znaków, z których użytkownik może wybierać, o ile te zasady są z jednej strony również egzekwowane i sprawdzane. To znaczy, jeśli użytkownik nie może używać \ w polu, nie wystarczy to sprawdzić w wejściu JS, ale także przed wpisaniem tego, tj. W DB i kiedy dane są używane. Tak więc zasady muszą obowiązywać przez cały czas (TOCTOU). Druga część jest taka, że ​​nie ma problemu ze zmniejszeniem zestawu znaków, o ile nadal jest podana entropia. Możesz zredukować znaki hasła do „a” i „b”, ale wtedy musisz odpowiednio zwiększyć minimalną długość PW (i sprawdzić, czy nie tylko przytrzymują klawisz „a”, dopóki nie będzie wystarczająco długi). Przy wystarczająco długim (losowym) haśle byłoby to również bezpieczne hasło W końcu wszystko, co jest do znaku, to bity, a każdy wie, że to 0 & 1, więc (prawdziwy) alfabet jest zawsze znany, jak jest wiele możliwych ustaleń, które musisz określić (i sprawdzić).