Jedną z myśli jest niedozwolone przesyłanie formularzy, jeśli w polu hasła nie ma wartości. Ogólnie rzecz biorąc, jeśli przypadkowo wpisali hasło w nazwie użytkownika, prawdopodobnie nie będzie niczego w oknie dialogowym hasła.

Warto zauważyć, że nie trzeba tego po prostu zrobić po stronie klienta, ale można również wykonać na serwerze, o ile używany transport jest bezpieczny, a dane wejściowe są rejestrowane dopiero po przejściu sprawdzenia, czy pole hasła nie jest puste.

Zakładając, że Twoja aplikacja zaplecza i SIEM muszą wyświetlić nieudane próby logowania do różnych aplikacji (i w ten sposób wyświetlić komunikat o błędzie „Użytkownik P @ $$ w0rd jest nieprawidłowy”), zatrzymanie tego nie będzie trywialne.

Jednak upewnienie się, że wszystkie aplikacje wysyłające poufne dane, w tym nazwy użytkowników i hasła, obsługują HTTPS (szyfrowany HTTP przy użyciu SSL), jest dobrym sposobem na zapewnienie, że urządzenia sieciowe i nikt w sieci nie może uzyskać hasła, które zostało omyłkowo wprowadzone w polu nazwy użytkownika!

Więc problem polega na tym, że nie chcesz, aby analitycy widzieli hasła w poufnych plikach dziennika?

Uwaga: nawet jeśli używałbyś Javascript, nie zajmuje się on danymi haseł przechowywanymi na dysku w postaci zwykłego tekstu.

Lepszym rozwiązaniem jest wstępne przetwarzanie dzienników, zanim analitycy je zobaczą, i zredagowanie informacji w dziennikach.

Możesz wykonać to filtrowanie linia po linii, jeśli umieszczasz na białej liście lub czarnej liście inne linie. Na przykład:

Możesz umieścić na białej liście nazwy użytkowników, które pojawiają się w pliku dziennika, które

• mają wzorzec ([az] + numer) lub ([az] + kropka + [az])
• dołącz nazwę domeny, po której następuje ukośnik „\” dla środowisk AD.
• pojawia się wiele razy
• Może być czyszczone z katalogiem LDAP zawierającym znane nazwy użytkowników, zanim analitycy go zobaczą.

Identyfikujesz i umieszczasz na czarnej liście hasła poprzez:

• Zasady dotyczące haseł często są zgodne z wzorcem (jeden symbol, górne / dolne, x znaków ...)

Możesz wykorzystać tę wiedzę do stworzenia niestandardowego narzędzia do czyszczenia danych dziennika, aby chronić informacje, których nie podałeś nie chcę, aby analitycy widzieli.

Jak więc wygląda przefiltrowana linia?

Możesz po prostu redagować wątpliwe nazwy użytkowników, haszując je, przypisując im ludzki identyfikator i przechowując je w bezpieczna lokalizacja:

  eb574b236133e60c989c6f472f07827b Redact1 7e67b89a695bfbffc05b7ed2c38f927f Redact2 ..etc  

Analitycy mogą sprawdzić, czy dany wpis powtarza się w kółko, jeśli częstotliwości.

Dokładna metoda mieszania (lub metoda szyfrowania), którą wybierzesz, wiąże się z ryzykiem, ponieważ ta „baza danych skrótów” będzie zawierała informacje o dużej wartości. A seeding (ze swej natury) zapobiegnie analizie częstotliwości, która może być dla Ciebie wartościowa lub nie.

Mogę zidentyfikować tylko trzy problemy z tym, o czym rozmawiasz.

1. Użytkownicy nie wprowadzają poprawnie informacji.
2. Analitycy mogą odróżniać hasła w dziennikach.
3. Hasła są wysyłane w postaci zwykłego tekstu i są podatne na podsłuchiwanie przez man-in-the-middle .

Moim zdaniem jest to dość proste do naprawienia.

1. Akceptuj błąd użytkownika, nieumyślnie.
2. Nie rejestruj nieprawidłowych nazw użytkowników, zamiast tego rejestruj nieudane próby i adres IP.
3. Nie wysyłaj nazw użytkowników zwykłym tekstem. Użyj technologii takiej jak HTTPS lub użyj javascript do zakodowania zwykłego tekstu (np. ROT13).

Przykładowy dziennik nieudanego logowania, a następnie udanej ponownej próby.

  [00:00:00] Logowanie nie powiodło się z 192.168.1.100 [00:21:00] Pomyślne logowanie „root” z 192.168.1.100  

Czytając inne odpowiedzi, chciałbym to załączyć.

• Sprawdź poprawność wszystkich pól przed przesłaniem.
• Rozważ podzielenie formularza na wiele stron, ponieważ Eric Wspomniał G.

Rozwiązaniem, które widziałem kilka banków, które wdrożyło, przynajmniej w aplikacjach internetowych, jest dwustronicowe logowanie.

1. Na pierwszej stronie zaakceptuj tylko nazwę użytkownika
2. Na następnej stronie w procesie poproś o hasło i powtórz tylko echo nazwy użytkownika, aby nie było to pole do edycji

Dlatego jedynym wpisem na drugiej stronie powinno być hasło. Ponieważ użytkownik wie, że musi wyczyścić pierwszą stronę nazwą użytkownika, wie, że musi wyczyścić tę bramę, wtedy jedyną opcją na drugiej stronie jest hasło.

Jeśli możesz zaimplementować ten przepływ pracy, pomoże on użytkownikom skoncentrować się na tym, co i kiedy piszą.

Biorąc pod uwagę logowanie: Może możesz zmienić sposób logowania nie uwzględniać rzeczywistych danych logowania?

Np. po pomyślnym zalogowaniu użyj identyfikatora klucza podstawowego zamiast powtarzania odpowiedzi: „Użytkownik o identyfikatorze: '2342342' próbował się zalogować”, a następnie „Użytkownik o identyfikatorze '2342342' pomyślnie podano hasło ”.

Jeśli wyszukujesz i nie ma tam nazwy użytkownika, to coś w rodzaju „Użytkownik z adresu IP '192.168.0.10' próbował zalogować się z nieprawidłowym identyfikatorem użytkownika”.

To byłyby dzienniki poziomu Twojej aplikacji. Dzienniki serwera WWW mogą zawierać parametry zapytań, więc może to być trochę trudniejsze do zaadresowania, albo może można umieścić jakiś rodzaj filtru proxy pomiędzy akcją a zapisem dziennika w celu redagowania zawartości dziennika na podstawie określonych reguł. Byłoby to zależne od platformy, ale wygląda na to, że jest to możliwe na Apache.

Jako dodatkowy element sterujący ogranicz dostęp do odczytu różnych przetwarzanych plików dziennika.

Ogólnie rzecz biorąc, cały kod klienta jest wystarczająco inteligentny, aby poradzić sobie z podstawowymi błędami

1. Brak identyfikatora użytkownika lub hasła
2. Hasło niezgodne z wytycznymi
ol>

W każdym razie, gdy nadal widzisz te wpisy w dzienniku,

  Użytkownik P @ $$ w0rd nie wychodzi [...] Konto nie zostało zalogowane: P @ $$ w0rd [...]  

Żadna z walidacji klienta nie zadziałała i system wysłał niezaszyfrowane hasło przez sieć. Więc co było w polu hasła? Zdecydowanie nie jest puste, ponieważ weryfikacja klienta zakończy się niepowodzeniem. Musi być coś innego niż hasło.

Więc niech to będzie uwierzytelnianie dwuprzebiegowe

1. First Pass, wyślij wszystkie zaszyfrowane dane, w tym hasło, do serwera. Sprawdź, czy pole Hasło jest puste.
2. Pierwsze przejście, sprawdź, czy hasło jest zgodne z wytycznymi w przeciwnym razie Błąd.
3. Pierwsze przejście, następnie sprawdź, czy hasło jest obecne w Twojej bazie danych. Jeśli nie wystąpił błąd.
4. Odeślij odpowiedź RPC do klienta i pozwól mu wysłać teraz identyfikator użytkownika i hasło.
5. Teraz przeprowadź proces uwierzytelniania.
ol >

Cała istotą tego procesu jest

1. Minimalizacja ryzyka. Uwaga, nie możesz wyeliminować ryzyka zerowego.
2. Brak zaufania do klienta.

I na koniec poproś eksperta UX o sprawdzenie interfejsu. Możliwe, że twój interfejs ma jakąś wadę, która powoduje, że Użytkownicy wpisują Hasło w polu ID.

Z tego, co opisujesz swoją architekturę, jest to niewykonalne, ale moim zdaniem poprawnym rozwiązaniem jest: Nie wysyłaj nazwy użytkownika w sposób jawny i nie rejestruj nazw użytkowników w przypadku nieudanych prób logowania. Jedynym miejscem, w którym powinna się znajdować nazwa użytkownika i hasło, jest podsystem sprawdzający hasło; dopóki to nie nastąpi, nazwa użytkownika jest nieuwierzytelnionymi, dowolnymi danymi - każdy, kto ma dostęp do formularza logowania, którym w aplikacji internetowej jest cały Internet, może wpisać wszystko, co chce, tak często, jak chce - i dlatego mówi bardzo mało interesującego. (Chyba że twój formularz logowania nie jest dostępny w Internecie.)

prawdopodobnie wyeliminowałoby to wiele analizy dziennika, ponieważ nie można było stwierdzić, kto co zrobił ....?

Biorąc pod uwagę nazwę użytkownika bez prawidłowego hasła, nie wiesz, że żądanie faktycznie pochodzi od tego użytkownika , więc nadal nie wiesz, kto wykonał próbę logowania.

Ogólnym problemem jest uwierzytelnianie za pomocą hasła. Każdy sklep typu mama i pop nalega na posiadanie własnego uwierzytelniania za pomocą haseł. To głupie.

Pozwól innemu dostawcy tożsamości wykonać ciężką pracę, aby zapewnić bezpieczeństwo poświadczeń. Zrób to samo, co robi StackOverflow: zezwól na uwierzytelnianie za pomocą OpenID, Gmaila itp.

Twoi użytkownicy będą Ci wdzięczni, że nie potrzebujesz gdzieś kolejnego hasła.

JavaScript po stronie klienta wydaje się rozsądny.

Sprawdź, czy pole hasła nie jest puste przed przesłaniem. Sprawdź, czy nazwa użytkownika ma prawidłową formę. Szczególnie eleganckie jest coś, w którym nazwa użytkownika musi być adresem e-mail. Możesz dodatkowo zabronić umieszczania hasła w mechanizmie ustawiania / zmiany hasła w postaci adresu e-mail. Następnie przed wysłaniem formularza po prostu sprawdź, czy nazwa użytkownika ma postać prawidłowego adresu e-mail. Można to zrobić podobnie za pomocą, powiedzmy, znaków specjalnych lub liczb. (Np. Cyfry / znaki specjalne są wymagane w hasłach, ale zabronione w nazwach użytkowników).

Dodatkowo używaj aktualnej biblioteki SSL dla wszystkich wysyłanych formularzy (należy to zrobić, aby uniemożliwić podsłuchiwanie podsłuchów sieciowych w). Wymagaj podwyższonych uprawnień do odczytu tych dzienników (np. Konto serwera WWW może zapisywać w tych dziennikach, ale tylko root może je odczytać). Gdy tylko hasło nie przejdzie kroku uwierzytelniania, nie propaguj nazwy użytkownika do innych systemów. (Używaj również SSL między różnymi systemami wewnętrznymi, aby zapobiec podsłuchiwaniu sieci).

Podoba mi się podejście, które moja obecna firma stosuje do tego problemu: jeśli wpiszesz hasło w niewłaściwym polu, zautomatyzowany system spowoduje natychmiastowe wygaśnięcie hasła. Dlatego użytkownik musi zmienić swoje hasło, a hasło, które jest w dzienniku, nie jest już podatne na ataki.

Oczywiście nadal nie jest to idealne rozwiązanie, jeśli użytkownik nadal używa tego hasła do innego systemu, ale miejmy nadzieję, że zmuszenie użytkownika do zmiany hasła sprawi, że użytkownik będzie bardziej świadomy możliwych zagrożeń bezpieczeństwa.

Przeważnie NAJŁATWIEJSZA odpowiedź jest poprawna. Teraz zauważamy, że każdy adres e-mail ma znak „@” tuż przed nazwą domeny. Uczynienie „@” kluczem NIEAKCEPTOWALNYM w haśle sprawia, że ​​rozwiązanie jest dość oczywiste. Jeśli nazwa użytkownika NIE ma @, a WSZYSTKIE NAZWY UŻYTKOWNIKÓW są adresami e-mail, wtedy Loguj tylko te, które mają co najmniej @.

Teraz, jeśli nazwa użytkownika NIE MA „@”, prawdopodobnie może to rozzłościć niektórych użytkowników, ale to jest zgrabne rozwiązanie. To znaczy mieć JEDEN POJEDYNCZY znak specjalny, który pojawia się PRZED hasłem. Podobnie jak WSZYSTKIE NAZWY UŻYTKOWNIKÓW, które są kontami e-mail, mają format. Wszystkie odpowiedzi mają specjalny charakter na początku lub na końcu. Więc kiedy użytkownik wprowadza hasło, dajesz mu znać, że musi je wpisać.

Trzecim rozwiązaniem jest KODOWANIE KOLORÓW. Zmień pole nazwy użytkownika na żółte i pole hasła na CZERWONE. Czerwony zwykle przyciąga twoją uwagę, ponieważ jest używany do delikatnych rzeczy. Więc nawet jeśli patrzą na klawiaturę, BARDZO SZYBKO DOWIEDZ SIĘ, że hasła są czerwone, więc zasadniczo pole tekstowe ORAZ etykieta hasła są czerwone, najlepiej w oddzielnym polu, a etykieta nazwy użytkownika i pole tekstowe CAŁKOWITE ŻÓŁTE.

Dlaczego po prostu nie odpowiedzieć?

  Ta nazwa użytkownika nie istnieje  

Jak dużą kontrolę masz nad obsługą tego serwera odbierającego? Wygląda na to, że rozwiązanie zaproponowane powyżej przez użytkownika, polegające na haszowaniu zarówno nazwy użytkownika, jak i hasła, byłoby możliwe do wykonania na kilka sposobów:

Metoda 1 (wymagająca JavaScript): Hash zarówno nazwę użytkownika, jak i hasło. W swojej bazie danych przechowuj zaszyfrowane nazwy użytkowników, a następnie przeprowadź wyszukiwanie uwierzytelniania, korzystając z tego pola. Byłoby to idealne rozwiązanie, jeśli masz pewną kontrolę nad sposobem traktowania danych na serwerze, ale nie kontrolujesz jego możliwości logowania.

Metoda 2 (niewymagająca JavaScript): Jak zwykle otrzymaj nazwę użytkownika w postaci zwykłego tekstu, ale przekonwertuj go na skrót, jak w metodzie 1, po otrzymaniu go na serwerze. Jeśli próba się nie powiedzie, zapisz skrót, a nie nazwę użytkownika. Dzienniki nadal będą przydatne (nieco mniej przydatne, gdy są sprawdzane kursorowo), ponieważ każdy hash nadal będzie jednoznacznie identyfikował użytkownika. Żadne z nich nie jest tak eleganckie, jak górna odpowiedź tutaj (i sugerowałbym użycie tego również), ale są dokładniejsze.

• zezwalają tylko na przesyłanie skrótów md5 nazw użytkowników ORAZ haseł (lub podobnych skrótów), dzięki czemu wszystko, co zostanie zarejestrowane w plikach dziennika, zawsze będzie wyglądało jak ustalona długość losowych znaków, co nie sprawi, że nikt szybko zgadnij, że jest to md5 hasła lub nazwy użytkownika.

Wada: Aby porównać nazwy użytkowników w swojej bazie danych, musisz zapisać dwie kolumny, np. „nazwa użytkownika” i „md5 (nazwa użytkownika)” LUB musisz dynamicznie haszować za każdym razem, gdy pytasz o nazwę użytkownika w celu zalogowania.

• utwórz wpis dziennika tylko wtedy, gdy nazwa użytkownika istnieje w bazie danych, w przeciwnym razie rejestruj tylko adres IP.

• tylko pozwól użytkownikowi na kliknięcie klawisza Enter za pomocą myszy, a nie klawiatury, lub zezwól na klawiaturę dopiero po 5 sekundach od ostatniego wpisanego znaku w dowolnym z pól, co da użytkownikowi czas na spojrzenie na ekran i zobaczenie swojego błędu.

• ogranicz dozwolone nazwy użytkowników i hasła:

  1. hasła muszą zawierać znak specjalny, taki jak! @ # $% ^ & * ()
  2. nazwy użytkowników NIE mogą zawierać żadnych znaków specjalnych

W ten sposób możesz wykonać javascript, aby szybko zidentyfikować, czy wprowadzona nazwa jest nazwą użytkownika lub hasło.

Prostym, ale irytującym rozwiązaniem może być ekranowy układ przycisków html, w którym użytkownicy mogą wpisywać swoją nazwę użytkownika tylko za pomocą tych przycisków, zapobiegnie to popełnieniu błędu, zdaję sobie sprawę, jak denerwujące może to zmienić być, ale po pierwszym logowaniu możesz użyć pliku cookie do zapamiętania nazwy użytkownika i nie wymagać jej ponownie. Oczywiście wymagany będzie Javascript. Teraz niemożliwe jest przypadkowe wysłanie hasła w postaci zwykłego tekstu. Mam nadzieję, że to pomoże.

Mam inne podejście ... Jaki problem naprawdę próbujesz rozwiązać?

1. Złe hasła? To znaczy. kiedy widzisz osobę używającą „hasła” (lub jego wariantu), chcesz mieć możliwość prześledzenia wstecz do użytkownika i poprawienia go?

2. Hasła są wysyłane w sposób niezawodny?

3. Albo problem z idiotami, którzy nie potrafią pisać ani czytać formularzy (albo może źle zaprojektowany interfejs użytkownika)?

Zawsze pamiętaj, że za każdym razem, gdy „dodajesz” do systemu, potencjalnie dodajesz złożoność i zdecydowanie dodajesz kod - oba te elementy zwiększają możliwość otwarcia gdzieś „dziur” w ogólnej architekturze (może to być stos, może być przez Internet, może być przez sieć ...). Więc rozwiązując którąkolwiek z tych trzech, musisz zmierzyć, czy wartość ich rozwiązania jest warta ryzyka wybicia dziury, o której nie wiesz - diabeł, którego znasz, jest zawsze lepszy niż diabeł, którego nie znasz.

Teraz do każdego.

Rozwiązywanie złych haseł powinno odbywać się podczas konfigurowania i zmiany hasła za pomocą reguł sprawdzania poprawności. I tylko tam. Dodanie innego miejsca, w którym można to zrobić, oznacza tylko ryzyko pomylenia reguł walidacji lub braku synchronizacji.

Hasła są wysyłane w sposób niezawodny. Kogo to obchodzi? To prawda, może wydawać się niebezpieczne, ale pamiętaj, że jest to uwierzytelnianie n częściowe, a jeśli masz tylko jedną część, nie różni się niczym od słowa w słowniku. Może, tylko może, jeśli masz aktywnego sniffera, może on dać im kilka wskazówek, ale wtedy włamanie już na miejscu jest twoim prawdziwym problemem, a nie jakimś sporadycznym, przypadkowym, grubym palcowaniem haseł w polu nazwy użytkownika. Teraz, jeśli wszystkie części są wysyłane z jasnym, dużym problemem.

Kwestia idiotów lub złego projektu interfejsu użytkownika. Ponownie zapośredniczaj użytkowników lub interfejs użytkownika. Prosty. Zapewnij aktywną pomoc w zakresie interfejsu użytkownika, poproś działy o szkolenie lub coś w tym stylu. Łatwa poprawka, która wymaga ograniczonych zmian w kodowaniu o niskim ryzyku (lub powinna - jednak uważać na aspekt interfejsu użytkownika).

Chociaż podziwiam wiele sugestii tutaj, a wiele z nich ma u podstaw wspaniałe pomysły. Polecam podejście KISS, bez BS, zawsze pamiętając, że dodając do swoich systemów ryzykujesz, że zwiększysz swoją niepewność.

Tylko moje 2 centy.

Biometria jest teraz dość niedroga i działa przez co najmniej 80% czasu. Uważam, że jest świetny na TabletPC i chciałem wdrożyć klawiatury biometryczne, ponieważ jest szybszy (przynajmniej przez 80% czasu).

Założę się, że nie był to aż tak duży problem z Win2000 , WinXP, Win2003 i WinVista, ponieważ domyślnie pole nazwy użytkownika było już wypełnione ostatnią pomyślną nazwą użytkownika. Nie jestem pewien, która wersja katalogu ActiveDirectory lub stacji roboczej uległa zmianie, ale domyślnie pole nazwy użytkownika jest puste, co sprawia, że ​​problem jest bardziej rozpowszechniony.