Nieudane próby logowania ujawniają hasła

Rozpocząłem rejestrowanie nieudanych prób logowania na mojej stronie za pomocą komunikatu typu

Failed login attempt by qntmfred

Zauważyłem, że niektóre z tych dzienników wyglądają

Failed login attempt by qntmfredmypassword

Zgaduję, że niektórzy ludzie mieli nieudane logowanie, ponieważ wpisali swoją nazwę użytkownika i hasło w polu nazwy użytkownika. Hasła są haszowane w bazie danych, ale jeśli w jakiś sposób baza danych zostanie przejęta, te komunikaty dziennika mogą być sposobem dla hakera na znalezienie haseł dla każdego niewielkiego odsetka osób, które nie mogą się zalogować.

Czy istnieje lepszy sposób, aby sobie z tym poradzić? Czy powinienem się martwić tą możliwością?

Spróbuj tak:

Jeśli nazwa użytkownika istnieje, zaloguj się „nieudana próba zalogowania przez username”. Jeśli nie, zaloguj się „nieudana próba zalogowania przez IP 123.45.67.89”. To powinno rozwiązać problem przypadkowego wyświetlania haseł w dzienniku.

Dlaczego nie po prostu sprawdzić, czy taka nazwa użytkownika istnieje w bazie danych? To da ci 2 możliwe wyniki.

1. Użytkownik wprowadził prawidłową nazwę użytkownika. Następnie możesz po prostu zalogować to, co teraz logujesz.

2. Użytkownik wpisał swoje hasło w polu nazwy użytkownika, dlatego nazwa użytkownika jest nieprawidłowa. Wystarczy wpisać wpis dziennika informujący, że próba zalogowania nie powiodła się przez niezidentyfikowanego użytkownika?

I oczywiście możesz mieć dodatkowe pole do rejestrowania adresu IP, daty, a co nie?

Uwagi:

1. Czy potrafisz wykryć, kiedy to nastąpiło, w przeciwieństwie do tego, że ktoś źle wpisał swoją nazwę użytkownika? Rejestrowanie błędnie wpisanych nazw użytkowników może być przydatne do celów wsparcia, tj. Odpowiedzi na pytanie „dlaczego nie mogę się zalogować” z odpowiedzią „Błędnie wpisałeś swoją nazwę użytkownika, która powinna być myślnikiem, a nie kropką”, lub „Masz wiodący dwukropek następnie spacja - czy to wytniesz i wkleiłeś ". Jeśli masz niewielką liczbę użytkowników o wysokiej wartości (tj. Nie jest to jeszcze inny serwis społecznościowy), prawdopodobnie będziesz musiał zapewnić tego rodzaju wsparcie.

2. Jakie właściwe działanie powinien ktoś zrobić? Nazwy użytkowników mogą wskazywać na próby włamania. Fakt, że nazwa użytkownika nie pojawia się na liście, nie oznacza, że ​​nie musisz wiedzieć, co to była. Jeśli jednak uważasz, że jest to poważny problem i możesz wykryć, czyje to hasło, możesz wymagać od użytkownika zmiany hasła po tym zdarzeniu.

3. Co to jest praktyka branżowa? Praktyką branżową jest rejestrowanie pola nazwy użytkownika, ale nie pola hasła. Jest mało prawdopodobne, że zostaniesz zwolniony z tego powodu.

Jeśli nie masz nietypowych względów, sugeruję przestrzeganie praktyki branżowej i rejestrowanie pola nazwy użytkownika, niezależnie od tego. Rozważ wymuszone zmiany hasła jako sugestię 2, jeśli uważasz, że jest to nieodpowiednie.

Dla bezpieczeństwa logowanie do mojej bieżącej aplikacji nie przechowuje parametrów przekazanych do metod logowania lub resetowania hasła. Wywołanie dziennika ma opcjonalny parametr, który to kontroluje, który po ustawieniu wartości true zastępuje obiekt parametrów przechowywanych parametrem [Redacted]. Jasne, więc brakuje mi trochę danych, ale mam ich adresy IP i wolałbym nie ryzykować uzyskania czegoś tak wrażliwego w postaci zwykłego tekstu.

Jeśli naprawdę chcesz rejestrować tego rodzaju rzeczy, sugeruję, aby logując się podczas próby zalogowania, sprawdziłeś bazę danych dla użytkowników o nazwie pasującej do tego, co masz w polu nazwy użytkownika, i przechowujesz ją tylko wtedy, gdy masz taką zgodność. W przeciwnym razie po prostu przechowujesz go jako „nieznany użytkownik”. Możesz być fantazyjny, sprawdzając, czy ta wartość zawiera to lub cokolwiek, ale zawsze istnieje ryzyko, że otrzymasz kombinacje takie jak [Użytkownik] [Hasło] i [UserPas] [miecz], w którym to przypadku możesz sprawdzić względem adresu IP i wydedukować to przypadkowo zapisałeś początek czyjeś hasło w sposób wyraźny. Możesz to rozszerzyć na mało prawdopodobne, ale możliwe [Użytkownik] [Hasło] i [Hasło użytkownika] [??], w którym to przypadku możesz zobaczyć „nieudane logowanie według hasła użytkownika”, a następnie „pomyślne logowanie użytkownika” i wydedukować wszystkiehasła użytkownika. Ogólnie, dla bezpieczeństwa powiedziałbym, że nie loguję nazw użytkowników, chyba że logowanie się powiedzie.

Edytuj, aby dodać:

Większość argumentów publikowanych przez użytkowników w celu zalogowania nazwy użytkownika w przypadku nieudanych prób logowania jest, moim zdaniem, lepiej obsługiwana innymi metodami.

Na przykład powiedziano, że gdy klient pyta „dlaczego nie mogę się zalogować?”, Zalogowane nazwy użytkowników pozwalają wskazać literówki. To prawda, ale nie warto ryzykować także wyłapywania haseł; Zrobiłbym to, przekierowując użytkownika z powrotem do formularza logowania w przypadku niepowodzenia, podświetlając pole nazwy użytkownika i ponownie wypełniając go tym, co wpisał, aby mogli sami zobaczyć.

Kolejnym argumentem było to, że pozwala zidentyfikować próby włamania; ciąg błędów w stosunku do jednej nazwy użytkownika może być próbą brutalnego wymuszenia hasła. Zrobiłbym to, mając kolumnę „BadLogins” w tabeli Użytkownicy, która jest zwiększana za każdym razem, gdy logowanie się nie powiedzie z nazwą użytkownika pasującą do tego użytkownika, i jest resetowane do zera po udanym logowaniu, po poinformowaniu użytkownika „były x nieudane próby logowania od ostatniego logowania ”i doradzanie im, co zrobić, jeśli nie sądzą, że próby były od nich. Jeśli chcesz być naprawdę dokładny, możesz mieć inną kolumnę, która przechowuje ostatnią wartość kolumny BadLogins, nawet po udanym logowaniu, i / lub kolumnę, która przechowuje najwyższą w historii wartość tej kolumny i / lub kolumnę, która przechowuje całkowitą liczbę nieudanych prób logowania na tym koncie.