Karanie użytkowników za niepewne hasła [zamknięte]

Zastanawiam się nad ograniczeniem praw użytkowników, którzy wybierają niebezpieczne hasła (niepewność hasła zależy od długości, liczby używanych znaków (wielkie / małe litery, cyfry, symbole itp.) I czy można znajduje się w tęczowej tabeli), aby ograniczyć szkody, które ich konto może wyrządzić, jeśli zostanie przejęte.

Nie mam jeszcze aplikacji na ten pomysł, ale mówię, że piszę forum lub coś takiego: użytkownicy, którzy używają hasła 1234 jako hasła, mogą być zmuszeni do wypełnienia captcha przed opublikowaniem lub podlegać rygorystycznym środkom antyspamowym, takim jak jako limity czasu lub filtry bayesowskie odrzucające ich treść. Jeśli to forum jest bardzo zhierarchizowane, co umożliwia „promocję” moderatorom lub cokolwiek w jakiś sposób, to albo powstrzyma ich przed uzyskaniem przywilejów, albo powie im, że mają przywileje, ale nie pozwoli im korzystać z nich bez zmiany na bezpieczniejsze hasło.

Oczywiście nie może to być jedyna miara bezpieczeństwa, ale może pójść dobrze obok dobrych praktyk bezpieczeństwa.

Co myślisz? Czy to po prostu przesadza, kradnie nacisk na ważniejsze praktyki bezpieczeństwa, czy jest to dobry sposób na ograniczenie ryzyka i zachęcenie użytkowników do korzystania z bezpieczniejszych haseł (i mam nadzieję, że przekonają osoby, które stosują dobre praktyki bezpieczeństwa)?

YAGNI , KISS , DRY , zasada 10 sekund i fakt, że „nie zależy na Tobie” powinno prawdopodobnie zawęzić to do jednego rozwiązania: Nie.

• To więcej prac programistycznych, które wymagałyby wielu testów, aby były niezawodne i bezpieczne.
• Prawdopodobnie zmniejsza to bezpieczeństwo witryny w dowolny sposób. Szansa, że ​​jakiś błąd prowadzący do eskalacji uprawnień ze strasznym hasłem jest po prostu zbyt duży.
• Zwiększa złożoność programisty, testera, opiekuna, DBA, sysadmin i użytkownika.
• Im większa złożoność, tym trudniej jest w jakiś sposób uniknąć powtarzania się.
• Użytkownicy nie skupiają uwagi na czytaniu twoich informacji i podejmowaniu dalszych działań. Służą do ulepszania formularza rejestracyjnego, dopóki nie zaakceptuje danych wejściowych, a nie do osiągnięcia idealnego poziomu.
• Użytkownicy nie dbają o to.

Wymuś bezpieczne hasło przy zmianie rejestracji lub użyj OpenId (Jeff Atwood's 2c: http://www.codinghorror.com/blog/2010/11/your-internet-drivers-license.html ). Następnie skoncentruj się na ciekawszej funkcjonalności.

Po pierwsze, użytkownicy są przyzwyczajeni do tworzenia bezpiecznych haseł lub korzystania z OpenId, więc jest to dla nich proste.

Po co pozwalać na hasła, które uważasz za złe? Zatrzymanie problemu u źródła pozwoli zaoszczędzić mnóstwo czasu na projektowanie, próbując dowiedzieć się, jakie klasy haseł odwzorowują na jakie role. Ponieważ administrator z definicji miałby pełne prawa, potrzebujesz już funkcjonalności, aby upewnić się, że nie wprowadzi hasła, które by go ograniczało.

Moja odpowiedź sprowadza się do KISS .

Jako użytkownik prawdopodobnie przekonałoby mnie to, że nie korzystam z Twojej witryny. Mówiąc poważnie, mój bank powiedział mi, że 6-cyfrowy kod jest całkowicie bezpieczny dla bankowości internetowej, ale kiedy chcę napisać komentarz do mniej znanego bloga, powinienem pamiętać unikalne hasło zawierające co najmniej 8 górnych - i małe litery, cyfrę, znak specjalny i symbol grecki lub cyrylicy, które można wprowadzić tylko wtedy, gdy znasz sekwencję Unicode na pamięć. I zmieniaj to regularnie.

Nie zrozum mnie źle, bezpieczeństwo jest ważne. Ale jeśli nie powinieneś denerwować użytkowników, chyba że masz naprawdę silny powód, by wierzyć, że ktoś spróbuje złamać hasło, aby uzyskać dostęp do Twojej witryny. Jeśli Twoja witryna zapewnia VPN dostęp do sieci FBI, śmiało. Ale jeśli jest to forum użytkowników, na którym każdy, kto ma adres e-mail, może się zarejestrować, to po co naprawdę?

Lepsze rozwiązanie: uśmiechnięte twarze.

Jestem poważny! Czytanie książek o ekonomii behawioralnej, takich jak „Posuwanie się: poprawa decyzji dotyczących zdrowia, bogactwa i szczęścia” przekonało mnie do kilku rzeczy:

1. Nie można zmusić wszystkich do podejmowania mądrych decyzji.
2. Ludzie lubią mieć swobodę wyboru, ale nie lubią wielu opcji.
3. Za pomocą prostych sztuczek możesz jednak znacząco wpłynąć na ich wybory.

Widzę, że te zasady odnoszą się do twojej sytuacji w następujący sposób:

1. Ograniczanie użytkowników na podstawie niepewnych haseł najprawdopodobniej spowoduje ich udaremnienie i dezorientację ... szczególnie w przypadku większości osób, które nie czytają dokładnie napisanych wyjaśnień w oknach dialogowych i po prostu dzwonią do działu pomocy technicznej, aby powiedzieć: praca."
2. Podczas tworzenia haseł użytkownicy nie muszą widzieć listy wszystkich możliwości znaków specjalnych i takich, z których mogą korzystać. Lepiej pokaż im wyskakujące okienko sugerujące, że dodają złożoności tylko wtedy, gdy ich wpis nie spełnia wymagań.
3. Ludzie są pod silnym wpływem wskazówek społecznych - nawet małe, takie jak szczęśliwe twarze, pokazujące, że aprobujemy ich zachowanie, lub powzięte twarze, jeśli nie. Niektóre z lepiej zaprojektowanych stron internetowych będą wyświetlać kolorowy pasek postępu, który zmienia kolor z czerwonego na Nieodpowiedni :( na zielony dla Dobra robota! :), gdy użytkownik wpisze (proponowane) hasło i potwierdzenie. Ten interfejs użytkownika wywiera na nich presję społeczną, aby spełnić standardy - sprawić, że pasek zmieni kolor na zielony lub zmienić zmarszczenie brwi w uśmiech - gdy sami odkrywają, jak tworzyć bezpieczniejsze hasła za pomocą natychmiastowej informacji zwrotnej zmiany kolorów.

Nie nakładać, ale pomyślałem o innym powodzie, aby zgłosić to w „Bad Idea”, o którym jeszcze nie wspominałem - obsługa klienta.

Jeśli jest to produkt, który będzie miał za sobą przedstawicieli obsługi klienta, nie spodoba mu się to zbytnio. Jednym z podstawowych założeń wsparcia jest to, że rozumieją i potrafią przewidzieć wrażenia użytkownika - jeśli pomagają zwykłemu użytkownikowi, strona 1 powinna zawierać linki do stron 2, 3 i 4, gdzie mogą wykonywać X, Y, Z itp.

Teraz dajesz im inną zmienną, którą muszą śledzić. Jeśli użytkownik nie widzi linku do strony 4, czy to dlatego, że zrobił coś głupiego? A może dlatego, że ich hasło jest do bani, a system karze ich, odmawiając im dostępu do strony 4? Chwila ... cholera, odmawia dostępu do jednej z kar za złe hasło, czy mam na myśli stronę 5? Spójrzmy na to, tylko chwila ... dobra, mówi, że dla hasła, które nie łączy wielkich i małych liter, dostęp do stron o parzystych numerach jest dozwolony, ale ograniczony tylko do odczytu ... dobrze, proszę pana, czy hasło składa się ze wszystkich wielkich lub małych liter? Walizka. Po prostu piszesz małą literę; kiedy używasz shift, wtedy jest to duża litera. Czy wymieszałeś przypadki w swoim haśle? Hasło użyte do zalogowania się do systemu. Ten, którego właśnie użyłeś. OK, przejdź do Edycja, a następnie wybierz Preferencje, a następnie Bezpieczeństwo. Wybierz „Zapisane hasła” ... nie, proszę pana, nie widzę stąd twoich haseł ...

Tak. Nie rób tego

Ogranicz hasła lub poinformuj użytkowników o ryzyku słabych haseł. Myślę, że jeśli użytkownik nie dba o swoje dane, możesz chcieć ograniczyć dostęp do danych innych. Być może użytkownicy czują się pewniej, jeśli osoby przestrzegające nieostrożnych haseł zostaną usunięte. Jaki jest sens wymagać silniejszego hasła, jeśli ma się on skończyć na karteczce pod klawiaturą lub przyklejonej do laptopa (Nie mogę tego wymyślić; Widziałem, jak to się dzieje).

i czy można go umieścić w tęczowym stole

Chyba masz na myśli słownik, a nie tęczowy stół. Atak słownikowy polega na sprawdzeniu wszystkich słów słownika, jeśli pasują do hasła. Ten atak można naprawić za pomocą 5 prób i blokowania na x minut ...

Tęczowa tabela będzie używana tylko wtedy, gdy hashujesz hasło, a atakujący zna hash. Niż mógłby znaleźć skrót w tęczowym stole, jeśli byłby to po prostu „12345” lub coś podobnego.

Aby dokończyć podróż w obie strony: aby uczynić tęczowy stół bezużytecznym, powinieneś solić hasła. I używaj unikalnej soli do każdego hasła, a nie tylko jednego dla wszystkich. Jeśli to zrobisz, atakujący musi utworzyć tęczowy stół z unikalną solą dla każdego konta, do którego chce uzyskać dostęp. Sprytnie zrobione po twojej stronie, możesz urozmaicić haszowanie za pomocą wielokrotnego algorytmu mieszania konkatenacji, aby jedno pokolenie mogło zająć pół sekundy. Jeśli to zrobiłeś, uzyskanie dostępu do konta w witrynie musi być warte dni, prawdopodobnie miesiąca generowania skrótów, aby znaleźć dopasowanie do tego konta ... Nie mogę myśleć o atakującym, który spróbuje uzyskać wszystkie hasła, kiedy to zrobi tak długo.

Dla czasu mieszania: Pomyśl o 500 ms czasu oczekiwania na mechanizm logowania. Myślę, że jest to dopuszczalne ... (przypomnienie: prawie jedna sekunda wymaga uścisku dłoni w przypadku SSL)