Jest to kwestia bezpieczeństwa i użyteczności, dlatego nie ma tutaj właściwej odpowiedzi. Oto moja opinia.

Jeśli możesz zachować nazwy użytkowników w tajemnicy, zrób to. W takim przypadku nie ma sposobu, aby dowiedzieć się, czy nazwa użytkownika istnieje, a login reaguje tak samo, czy użytkownik istnieje, czy nie. Zwróć uwagę, że oznacza to również poświęcenie takiej samej ilości czasu na zwrócenie komunikatu o błędzie.

Takie zachowanie może nie być możliwe. Na przykład, jeśli użytkownicy mogą się zarejestrować i wybrać własną nazwę użytkownika, musisz powiadomić ich, gdy nazwa użytkownika już istnieje w systemie. W takim przypadku należy maksymalnie uprościć logowanie, podając najbardziej szczegółowy komunikat o błędzie. Jeśli ktoś może dowiedzieć się, czy użytkownik istnieje, korzystając z funkcji rejestracji, nie ma sensu ukrywać tego przy logowaniu.

To nie jedyne wytyczne OWASP, których nie przestrzegają duzi gracze. OWASP często koncentruje się na bezpieczeństwie i ignoruje użyteczność. Może to być ważny wybór projektu, jeśli połączy się go z przyzwoitą polityką haseł, ochroną brutalnej siły (blokada, captcha, ..), MFA, monitorowaniem nieudanych prób logowania itp.

Weź pod uwagę wyliczenie użytkowników to nie tylko problem z możliwością odgadnięcia kont użytkowników, które można później brutalnie wykorzystać do uwierzytelnienia. Niektóre witryny powinny chronić prywatność swoich użytkowników (osoby dorosłe, partie polityczne, randki itp.). Jeśli chcę sprawdzić, czy mój szef korzysta z witryny dla dorosłych, mogę niewłaściwie wykorzystać lukę w liczbie użytkowników, aby wiedzieć, z jakich witryn korzysta.

Po prostu nie możesz temu zapobiec. (Chyba że jesteś gotów poświęcić znaczną część użyteczności).

Wyliczanie użytkowników może być niepożądane i rzeczywiście istnieje potencjał konsekwencje dla bezpieczeństwa (np. jeśli napastnik odkryje, że istnieje prawidłowe konto o nazwie admin , do którego może próbować uzyskać dostęp). Ale w przypadku dużych witryn nie można tego powstrzymać.

Nawet jeśli nie ujawnisz podczas logowania, że ​​użytkownik nie istnieje, w końcu będziesz musiał ostrzec nowych użytkowników, gdy będą próbowali zarejestruj już zajęte imię lub z już używanym adresem e-mail .

Nie ma przyjaznego dla użytkownika sposobu obejścia tego problemu:

Bezpieczeństwo jest względne. Nieco bezpieczniej jest nie podawać informacji o tym, czy konto istnieje, czy nie. Ale to nie znaczy, że przekazywanie takich informacji jest niebezpieczne. Jest to po prostu mniej bezpieczne i tylko nieznacznie.

Jest to szczególnie prawdziwe w przykładach, które podajesz; istnieją inne sposoby znajdowania nazw kont, więc próba ukrycia, czy konto istnieje, nie przynosi korzyści.

Podobnie jak w przypadku każdej formy zabezpieczenia przez zaciemnienie, ukrywanie konta nazwy to słaba kontrola bezpieczeństwa i potrzebne są inne kontrolki.

Zgadzam się z odpowiedzią @ Silver, ale chcę się rozszerzyć. Pamiętaj o kontekście; Wytyczne OWASP mają służyć jako praktyczne zasady dla programistów, którzy nie są ekspertami w dziedzinie bezpieczeństwa. Jeśli firma programistyczna ma zespół utalentowanych architektów bezpieczeństwa, nie musi ślepo przestrzegać praktycznych reguł, o ile rozumieją intencje reguł i ograniczają ryzyko w inny sposób.

Analogia: powinieneś wymieniać olej w samochodzie co 3 miesiące lub co 5000 km, ale mechanicy samochodowi często naciskają dłużej, gdy wiedzą, że ich nawyki jazdy są dobre. I to jest w porządku.

Jeśli chodzi o szczegóły, nie jestem ekspertem w wyliczaniu użytkowników ani nie wiem, dlaczego Google i Microsoft podjęły takie decyzje, ale zakładam, że wprowadzili ograniczenia szybkości i czarną listę, aby zapobiec atakom na dużą skalę polegający na wyliczaniu użytkowników, a poza tym zdecydowali, że wygoda użytkownika jest warta dodatkowego ryzyka.

Prawdopodobnie zbyt trudno jest powiedzieć, że naruszają wytyczne OWASP, ponieważ w przypadku aplikacji i usług takich jak Google czy Microsoft muszą one być maksymalnie „zgodne z wymaganiami użytkownika”.

Ponadto wszystkie mają lub oferuj protokoły 2FA.

Celem nieujawniania aktywnego identyfikatora użytkownika jest zapobieżenie wyliczeniu dużej liczby kont.

Ściśle mówiąc, możesz się przed tym chronić, zezwalając na zduplikowane konta, ale to straszny projekt i doprowadzi Cię do wszelkiego rodzaju kłopotów.

Innym sposobem na to jest przypisanie użytkownikom identyfikatora - skonstruowanie takiego, który jest nieużywany. Jest to jednak tak słaba użyteczność, że może nie być tego warta *.

Rozsądnym sposobem zminimalizowania ryzyka jest wdrożenie wszelkich zabezpieczeń - funkcja wyliczania - na przykład dobrej jakości captcha, aby spowolnić każdą próbę wyliczenia. Wtedy projekt jest w miarę bezpieczny.

Ryzyko szczątkowe polega na tym, że pozostawiasz otwartą weryfikację jednego konta o bardzo dużej wartości - na przykład barack .obama @ gmail.com. Następnie zmniejszasz to ryzyko, wdrażając kontrolę przed próbami złamania haseł itp.

* Salzer i Shroeder, Ochrona informacji w systemach komputerowych, sekcja IA3 ) h) Akceptowalność psychologiczna: Istotne jest, aby interfejs ludzki był zaprojektowany tak, aby był łatwy w użyciu, tak aby użytkownicy rutynowo i automatycznie stosowali prawidłowo mechanizmy ochrony. Ponadto, w zakresie, w jakim mentalny obraz użytkownika jego celów ochronnych pasuje do mechanizmów, których musi użyć, błędy zostaną zminimalizowane. Jeśli będzie musiał przetłumaczyć swój obraz swoich potrzeb w zakresie ochrony na radykalnie inny język specyfikacji, popełni błędy.