Nie zgadzam się z kimś (klientem) w sprawie procesu identyfikacji / uwierzytelnienia użytkownika w systemie. Najważniejsze jest to, że chcą, aby każdy użytkownik miał globalnie unikalne hasło (tzn. Żaden z dwóch użytkowników nie może mieć tego samego hasła). Wyłożyłem wszystkie oczywiste argumenty przeciwko temu (jest to luka w zabezpieczeniach, myli identyfikację z uwierzytelnianiem, jest bezcelowa itp.), Ale nalegają, aby w tym podejściu nie było nic złego.
Przeprowadziłem różne wyszukiwania w Google, szukając autorytatywnych (półpoważnych, a nawet po prostu niezależnych) opinii na ten temat, ale nie mogę znaleźć żadnych (głównie jest to tak oczywisty faux pas, że nie warto go ostrzegać, ponieważ o ile mogę powiedzieć). Czy ktoś może mi wskazać taką niezależną opinię?
[EDYCJA]
Dziękuję za wszystkie odpowiedzi, ale już rozumiem problemy z tym proponowanym podejściem / wymaganiem i mogę nawet wyjaśnić je klientowi, ale klient ich nie zaakceptuje, stąd moja prośba o niezależne i / lub wiarygodne źródła .
Znalazłem również artykuł Daily WTF, ale cierpi na problem, na który zwrócił uwagę Jon Hopkins - że jest to tak oczywiste WTF, że nie warto wyjaśniać, dlaczego .
I tak, hasła będą solone i mieszane. W takim przypadku globalna wyjątkowość może być trudna do zapewnienia, ale to nie rozwiązuje mojego problemu - oznacza to tylko, że mam wymaganie, aby klient się nie ruszył, co jest nie tylko nierozsądne, ale także trudne wprowadzić w życie. A gdybym był w stanie powiedzieć „Nie mam ochoty na solenie i mieszanie”, to byłbym w stanie powiedzieć „Nie wdrażam globalnie unikatowych haseł”.
Wszelkie wskazówki do niezależnych i / lub autorytatywnych źródeł, dlaczego jest to zły pomysł, wciąż z wdzięcznością otrzymane ...
[/ EDIT]
Odpowiedzi:
Za każdym razem, gdy klient próbuje utworzyć hasło, które już istnieje, otrzymuje informację zwrotną, że niektórzy użytkownicy już go używają, co zwykle stanowi naruszenie umowy o prywatności.
Oprócz tego nazwy użytkowników są znacznie łatwiejsze do odgadnięcia (a jeśli istnieje forum, możesz po prostu znaleźć tam wiele nazw użytkowników) i sugerujesz użytkownikom sposoby włamania się na stronę.
Gdzieś w Internecie powinna znajdować się strona opisująca część dotyczącą naruszenia umowy o prywatności, poza tym, że jest to po prostu zdrowy rozsądek: w zasadzie dałby komuś klucz i listę adresów domowych.
EDYCJA: Nie jest zbliżona do autorytatywnej, ale być może pomocna po wyjaśnieniu, co oznacza WTF: http://thedailywtf.com/Articles/Really_Unique_Passwords.aspx
źródło
Najlepsza praktyka przeszkadza w spełnieniu wymagania:
Nie możesz tego zrobić, ponieważ nie wiesz, jakie są hasła, więc nie możesz ich porównać, ponieważ wszystko, co przechowujesz, to skrót hasła i sól (którą możesz przechowywać obok hasła z hasłem). To najlepsza praktyka, więc to właśnie robisz. Gotowy.
Kolejna edycja: Doh! Perspektywa jest łatwa - nadal możesz sprawdzić wyjątkowość, ponieważ (oczywiście) masz sól ... po prostu zastrzel mnie teraz ... oczywiście nie musisz wspominać klientowi o tych szczegółach.
FWIW, to nie jest tak głupie, jak myślisz, że jest - celem jest uniemożliwienie grupom użytkowników uzgadniania i udostępniania tego samego hasła, co zrobią ludzie w przekonaniu, że ułatwi im to życie.
Jeśli zastosuje się go z wymogiem regularnej zmiany hasła i ograniczeniem, które uniemożliwia ponowne użycie obecnego lub poprzednio używanego hasła (w ogóle, kiedykolwiek) i rozsądne wymagania dotyczące „siły” (lub przynajmniej wstępnie załadowanego słownika „zablokowane” „hasła) dojdziesz do punktu, dość szybko, gdzie szanse i tak nie są na korzyść hakera.
Ok, moja odpowiedź pierwotnie rozpoczęła się od:
Najwyraźniej niewłaściwy humor - chodziło o to, że jeśli nie masz globalnie wyjątkowego ograniczenia, tworzysz różne możliwości, być może mniej niebezpieczne - nie wiem.
źródło
Egzekwowanie niepowtarzalnych haseł powoduje wyciek informacji
W jaki sposób? Ponieważ za każdym razem, gdy cracker próbuje utworzyć nowego użytkownika za pomocą prostego hasła, twój system odpowiada „Nie, nie mogę mieć tego hasła”, cracker mówi „Goody, to jedno z listy”.
Wyciek informacji o twoim bezpieczeństwie jest na ogół złą rzeczą. OK, osoby trzecie znające algorytm są w porządku (wymaga weryfikacji), ale zezwalają dedykowanemu crackerowi na wnioskowanie o kluczach - źle, naprawdę bardzo źle.
Zasoby opisujące dobre i złe zasady zarządzania hasłami
Przeczytaj ten artykuł eksperta ds. Bezpieczeństwa Bruce'a Schneiera, aby uzyskać szczegółowe omówienie siły hasła.
Przeczytaj ten plik PDF badacze bezpieczeństwa Philip Inglesant i M. Angela Sasse, aby zapoznać się z dogłębną dyskusją na temat „Prawdziwego kosztu niepotrzebnych haseł”. Cytat z konkluzji:
Fałszywe poczucie bezpieczeństwa
Tak więc klient mówi: „Jeśli nikt nie ma tego samego hasła, jeśli zostanie złamany, dotyczy to tylko jednej osoby”. Nie. Dotyczy to wszystkich, ponieważ cracker wykazał, że twój system haseł jest zasadniczo wadliwy: jest podatny na atak słownikowy w systemie on-line. W pierwszej kolejności krakersy nie powinny próbować zgadywać hasła.
Do dostępu on-line wystarczy 6 znaków
Wychodzę z tematu, ale pomyślałem, że warto o tym wspomnieć zainteresowanym czytelnikom. Pod względem bezpieczeństwa system on-line to taki, który ma aktywny proces zarządzania bezpieczeństwem monitorujący i kontrolujący dostęp do danych. System offline to taki, który tego nie robi (np. Ma zaszyfrowane dane na skradzionym dysku twardym).
Jeśli masz system haseł online, nie potrzebujesz haseł o wysokim poziomie bezpieczeństwa. Hasła muszą być wystarczająco złożone, aby zapobiec zgadywaniom w ciągu 20 prób (więc prosty atak „imię małżonka / dziecka / zwierzaka” zakończy się niepowodzeniem). Rozważ następujący algorytm:
W przypadku prostego hasła składającego się z 6 znaków powyższy algorytm zapobiegnie atakom słownikowym, umożliwiając w końcu nawet najbardziej nieudolnemu użytkownikowi mobilnej klawiatury. Nic nie zapobiegnie tak zwanemu „atakowi gumowego węża”, w którym pobijesz posiadacza hasła gumowym wężem, dopóki ci nie powie.
W przypadku systemu offline, gdy zaszyfrowane dane leżą na dysku flash, a cracker może wypróbować coś przeciwko niemu, potrzebujesz najbardziej odpornego klucza, jaki możesz znaleźć. Ale ten problem został już rozwiązany .
źródło
Jeśli odradziłeś im ten sposób działania i podałeś im powody, wziąłbym ich za słowo i wdrożyłbym system, jak sugerują. Może to nie być satysfakcjonujące, ale wykonałeś swoją pracę, a oni pokrywają rachunek, więc powinni dostać to, czego chcą.
Jest jeden wyjątek. Jeśli negatywne konsekwencje naruszenia systemu byłyby poważne (np. Jeśli bardzo prywatne informacje mogą zostać naruszone przez naruszenie bezpieczeństwa), możesz faktycznie mieć zawodowy obowiązek nie wdrożyć pożądanego systemu. Nie oczekuj, że zwiększy to twoją popularność, jeśli odmówisz, ale nie pozwól, aby to był twój przewodnik.
źródło
Chcę tylko wzmocnić odpowiedź Murpha. Tak, jest to problem z bezpieczeństwem i istnieją luki w ujawnianiu informacji podczas jego wdrażania. Ale z punktu widzenia klienta nie wydaje się zbytnio tym martwić.
Należy zwrócić uwagę na fakt, że fizycznie niewykonalne jest sprawdzenie „unikalnego hasła”. Jeśli solisz i hashujesz hasło, a nie przechowujesz ich jako czysty tekst, to O (n) (drogie) operacje faktycznie wykonują sprawdzenie unikalności.
Czy możesz sobie wyobrazić, że masz 10 000 użytkowników, a sprawdzenie hasła każdego użytkownika zajmuje 30 sekund, aby sprawdzić niepowtarzalność za każdym razem, gdy ktoś rejestruje się lub zmienia hasło?
Myślę, że to odpowiedź, którą musisz podjąć u swojego klienta.
źródło
Po prostu zastanawiając się nad odpowiednim miejscem do zadawania pytań, sekcja bezpieczeństwa IT w Stack Exchange powinna być dla Ciebie przydatna. Wypróbuj /security/tagged/passwords - szereg osób zajmujących się bezpieczeństwem IT powinno być w stanie udzielić konkretnych odpowiedzi.
źródło
Prawdopodobnie chciałby szyfrowanie RSA dwuskładnikowe. Jeśli korzystasz z Active Directory lub członkostwa ASP.NET, jest to oczywiste.
Token sprzętowy lub programowy generuje zależne od czasu unikalne hasło, po którym następuje kod PIN. To razem zapewnia unikalne hasło dla każdego użytkownika.
źródło