Jeśli złośliwy użytkownik zacznie atakować witrynę, odgadując typowe kombinacje nazwy użytkownika i hasła, takie jak admin / admin, atakujący będzie wiedział, że nazwa użytkownika jest prawidłowa, jeśli zwraca komunikat „Hasło nieprawidłowe” zamiast „Nazwa użytkownika lub hasło nieprawidłowe” .

Jeśli atakujący wie, że nazwa użytkownika jest prawidłowa, może skoncentrować swoje wysiłki na tym konkretnym koncie, używając technik takich jak wstrzyknięcia SQL lub brutalne forsowanie hasła.

Jak wspominali inni, nie chcemy, abyś wiedział, czy to nazwa użytkownika lub hasło były błędne, abyśmy nie byli tak podatni na brutalną siłę lub słownikowe ataki ..

Jeśli niektóre witryny chciałyby poinformować swoich użytkowników, która z nich się nie powiodła, mimo że nadal są na zielono pod względem bezpieczeństwa, mogliby zaimplementować „ honeypot” nazwy użytkownika (takie jak Administrator, admin itp.), które ostrzegałyby administratorów witryn, że ktoś węszy w ich witrynie. Mógłbyś nawet ustawić logikę blokowania ich adresów IP, gdyby próbowali zalogować się przy użyciu jednej z tych nazw użytkowników „honeypot”. Znam jedną osobę, która faktycznie miała stronę internetową i umieściła w swoim kodzie źródłowym komentarz HTML, taki jak „Odkąd ciągle zapominasz Richarda: Nazwa użytkownika: cheese Hasło: Burger123” w pobliżu pola logowania z zamiarem monitorowania każdego adresu IP, który próbował użyć ta nazwa użytkownika / hasło. Dodanie takiej logiki monitorowania to świetna zabawa podczas tworzenia strony internetowej.

Oczywiście rejestrowanie nieprawidłowych prób logowania i dodawanie odpowiedniej logiki do obsługi tych adresów IP również działa. Wiem, że niektórzy by się ze mną nie zgodzili, ale w zależności od rodzaju witryny internetowej nie wydaje mi się, aby powiadomienie użytkownika było zbyt skomplikowane, o ile dodasz dodatkowe środki bezpieczeństwa w celu zapobiegania różnego rodzaju atakom.

Moja ulubiona bezpieczna implementacja jest wykonywana przez bank, z którego korzystam. Jeśli poprawnie wpiszę swoją nazwę użytkownika, powie: „Witaj Jimbob!” a następnie wyświetla monit o udzielenie odpowiedzi na pytania zabezpieczające (jeśli nigdy nie logowałem się z tej przeglądarki na tym komputerze), poczekaj, aż odpowiem poprawnie na pytania zabezpieczające, a następnie pokaże mi mój obraz / podpis zabezpieczający i wprowadzę hasło. Jeśli wpiszę niewłaściwą nazwę użytkownika, zobaczę coś w stylu „Witaj Bessie / Kareem / Randal!” gdzie wyświetlana nazwa jest bardzo rzadka - chociaż zawsze będziesz mieć tę samą nazwę dla tej samej nazwy użytkownika (zwykle nie mam pewności co do jednej lub dwóch nazw użytkownika; a niewłaściwa nazwa konsekwentnie nazywa mnie Frenshelia). Zakładam, że został zaimplementowany jako jakiś rodzaj niekryptograficznego skrótu zastosowanego do dowolnej wprowadzonej nazwy użytkownika, która w unikalny sposób mapuje jedną nazwę użytkownika na długiej liście dość nietypowych nazw. Dzięki temu uprawnieni użytkownicy wiedzą, czy wpisali niewłaściwą nazwę użytkownika (na przykład, jeśli masz niezwykłą nazwę, taką jak Bessie; jest bardzo mało prawdopodobne, że zła nazwa użytkownika, którą przypadkowo odgadłeś, odwzorowuje z powrotem na Twoje konkretne, niezwykłe imię), nie czyniąc tego oczywistym dla osób próbujących aby znaleźć losowe konta, których nazwa użytkownika nie istnieje.

Na marginesie: nie przepadam za kwestiami bezpieczeństwa / obrazami bezpieczeństwa, które wydają się graniczyć z teatrem bezpieczeństwa. Zaawansowany napastnik przeprowadzający atak typu man-in-the-middle (MITM) (np. Po zainstalowaniu fałszywych certyfikatów w Twojej przeglądarce internetowej i spoofingu DNS / ARP w celu wskazania twojemu bankowi.com adresu IP) może poczekać, aż spróbujesz się zalogować do witryny, a następnie zautomatyzowany skrypt zaloguj się na swoim komputerze do prawdziwej witryny, otrzymaj pytania zabezpieczające, wyświetl wybrane pytania bezpieczeństwa z powrotem, odeślij odpowiedzi do witryny samodzielnie z przeglądarki, poczekaj na zabezpieczenie image, podaj z powrotem obraz bezpieczeństwa, a następnie poczekaj, aż wprowadzisz hasło od ich końca, w którym to momencie używają hasła, aby zalogować się jako Ty i robić złośliwe rzeczy. Przyznanie pytań + obraz sprawia, że ​​proces jest trudniejszy niż cały czas na świecie, aby zebrać wszystkie obrazy bezpieczeństwa dla różnych zaatakowanych nazw użytkowników, zamieniając je w atak, który należy wykonać w czasie rzeczywistym i prawdopodobnie pozostawia podejrzany podpis .

Inne odpowiedzi zapewniają dobry wgląd w przyczyny bezpieczeństwa stojące za tym zachowaniem. Chociaż są poprawne, jestem prawie pewien, że przynajmniej niektóre strony internetowe mają zaprogramowaną procedurę autoryzacji w taki sposób, że nie można stwierdzić, co było nie tak - login lub hasło.

Przykład zapytanie:

  SELECT COUNT (*) FROM users WHERE login = 'john' AND hash = '2bbfcdf3f09ae8d700402f36913515cd'  

Zwróci to 1 po udanej próbie logowania i 0 jeśli nie ma użytkownika o takiej nazwie lub ten użytkownik ma inne hasło. Nie ma sposobu, aby stwierdzić, która część warunku zawiodła. Więc jeśli chodzi o wyświetlanie komunikatów o błędach, programista szczerze mówi ci, że coś jest nie tak i nie jest do końca pewien, co to jest.

Osobiście widziałem podobne zapytania na kilku stronach opartych na PHP, więc Jestem prawie pewien, że część tego powodu pochodzi ze sposobu kodowania procesu uwierzytelniania, tak naprawdę.

Istnieje jednak inna interesująca technika, którą można zastosować do wykonania ataku na wyliczenie użytkowników (i nie tylko). Nazywa się to atakiem czasowym . Atakujący po prostu mierzy czas odpowiedzi na żądanie uwierzytelnienia i różnicę między prawidłowym a nieprawidłowym loginem.

1. Zdalne ataki czasowe w skali nanosekundowej na aplikacje PHP: czas potraktować je poważnie ?
   http://blog.astrumfutura.com/2010/10/nanosecond-scale-remote-timing-attacks-on-php-applications-time-to-take-them-seriously/

2. Lekcja synchronizacji ataków
   http://codahale.com/a-lesson-in-timing-attacks/

3. Stałe porównywanie ciągów czasowych w PHP w celu zapobiegania atakom czasowym
   https://codereview.stackexchange.com/questions/13512/constant-time-string- porównanie-w-php-do-zapobiegania-atakom-czasowym

Chodzi mi o to, że taka wiadomość nie wystarczy, jeśli chcesz zabezpieczyć swoją aplikację przed tego rodzaju zagrożenie.

Powód związany z bezpieczeństwem jest taki, że w przeciwnym razie znacznie łatwiej będzie znaleźć prawidłowe nazwy użytkownika.

Oprócz wszystkich wspaniałych odpowiedzi, które już zostały udzielone, istnieje ogólna zasada bezpieczeństwa, która mówi, że nie należy podawać niechcianych informacji nieautoryzowanym użytkownikom. To znaczy. jeśli masz możliwość wyboru odpowiedzi „Twoje dane uwierzytelniające są nieprawidłowe” lub wyjaśnienia, która część jest nieważna - zawsze powinieneś wybrać tę pierwszą. Niektóre bardzo nieprzyjemne ataki kryptograficzne opierają się na najmniejszej ilości informacji o błędach dostarczonych przez implementację, która stara się być „pomocna” - patrz Atak Padding oracle. Dlatego dobrym pomysłem jest zawsze wybieranie możliwie najmniejszej ilości informacji ujawnianej nieautoryzowanemu podmiotowi - tj. Jeśli jego kombinacja nazwy użytkownika / hasła nie jest dobra, zawsze odpowiadasz „nazwa użytkownika / hasło nie jest dobre” i nigdy więcej nie ujawniaj dane. Nawet jeśli w konkretnym przypadku (np. W Gmailu, gdzie nazwa użytkownika jest publiczna) nie jest to ważne, dobrze jest przyjąć ją domyślnie.

Załóżmy, że wpisujesz losową nazwę użytkownika i równie losowe hasło (pamiętaj tylko, jakie hasło wprowadzasz). Teraz hasła mogą być wspólne dla n użytkowników. Tak więc, jeśli witryna mówi, że hasło jest poprawne ... to wiesz, co nastąpi dalej ... chaos wśród prawdziwych użytkowników, ponieważ uzyskanie nazw logowania jest dość łatwe.

Podanie niejednoznacznej odpowiedzi jest przydatne, aby zapobiec atakowi wyliczenia użytkowników.

W niektórych przypadkach osoba atakująca nie musi włamać się na konto użytkownika. Informacje, że użytkownik ma konto, są wystarczające bez żadnych innych działań. Na przykład cenną informacją dla handlu jest to, że ich klient ma konto w konkurencyjnym sklepie internetowym.

Doceniam różne odpowiedzi powyżej, ponieważ mówią one najbardziej, ale czasami aplikacje nie wiedzą, co jest błędną nazwą użytkownika lub hasłem. W przypadku uwierzytelniania opartego na tokenach specjalnie do implementacji SSO (Single Sign On) np. IBM Tivoli Access Manager aplikacja otrzyma pomyślny token lub zwraca błąd.

jeśli login jest adresem e-mail, łatwo jest stwierdzić, że dana osoba jest zarejestrowana na stronie internetowej - mogę tego nie chcieć >> Czasami ludzie używają prawdziwego hasła konta e-mail do witryn, które rejestrują, gdy używają identyfikatora e-mail jako loginu id :)