Nieudane próby logowania ujawniają hasła

38

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ą?

kenwarner
źródło
14
Tak, powinieneś się tym martwić.
FoolishSeth
4
Ciekawe pytanie, ponieważ przecina UX i bezpieczeństwo. Jak zauważono w jednym z łączy Michaela, możesz zapobiec większości przypadków za pomocą Javascript (po stronie klienta). Wyłącz przycisk Zaloguj się, gdy pole hasła jest puste. Użytkownicy bez Javascript mogą nadal korzystać z ekranu logowania w ten sposób, ponieważ w takim przypadku przycisk nie zostanie wyłączony.
MSalters

Odpowiedzi:

65

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.

Mason Wheeler
źródło
14
Możesz również sprawdzić, czy hasło jest puste, i w takim przypadku nie powiedzie się odpowiedni błąd.
Mike Weller,
Drukowanie nazwy użytkownika to problem opisywany przez OP. Czasami nieudane logowanie jest spowodowane brakiem klawisza [tab] i szybkim wpisaniem nazwy użytkownika i hasła w polu nazwy użytkownika i naciśnięciem klawisza Enter. Twoja sugestia tego nie rozwiązuje.
BZink
7
@BZink: Tak. Jeśli nazwa użytkownika istnieje , zarejestruj ją jako taką. Jeśli to, co zrobi użytkownik, przypadkowo doda hasło do nazwy użytkownika, wynikowy ciąg prawie na pewno nie będzie również prawidłową nazwą użytkownika.
Mason Wheeler
12

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?

galdikas
źródło
3
Dlaczego nie dołączyć skrótu nazwy użytkownika do wpisu dziennika w # 2. Spowoduje to ukrycie hasła, ale jednocześnie pozwoli komuś przeglądając dzienniki ustalić, czy ten sam niezidentyfikowany użytkownik podejmie wiele prób.
emory
Jeśli nie ma rekordu zawierającego nazwę użytkownika, jest oczywiste, że źle go zrozumieli, więc nadal jest przydatny do rozwiązywania problemów.
JeffO
2
@emory, jeśli użytkownik błędnie wpisał swoje hasło wraz z nazwą użytkownika, nie ma realnego sposobu na wyodrębnienie tylko części nazwy użytkownika z ciągu. I ktoś, kto wielokrotnie wpisuje hasło do pola nazwy użytkownika, jest bardzo mało prawdopodobny. To popełniany przez ciebie błąd „jednorazowy”. Dzieje się tak w najlepszym z nas, ale wątpię, żeby ktoś był na tyle głupi, żeby to robić, nie zdając sobie z tego sprawy: D
galdikas
@galdikas Nie trzeba wyciągać niczego z nazwy użytkownika. Na przykład jestem użytkownikiem „użytkownik” z hasłem „hasło”. Loguję się przy użyciu „hasła użytkownika”, a funkcja skrótu odwzorowuje „hasło użytkownika” na 17. Logi mówią „Nieudana próba logowania przez niezidentyfikowanego użytkownika 17”.
emory
1
@galdikas Prawdopodobnie nie ma nikogo na tyle głupiego lub uporczywego, aby robić to więcej niż kilka razy, ale są skrypty, które są na tyle głupie i trwałe, aby zrobić to tysiące razy. Czy nie chciałbyś poznać różnicy?
emory
1

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.

Ben
źródło
1

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.

anaksymander
źródło