sudo: 3 nieprawidłowe hasła - czy root może zobaczyć hasło w postaci zwykłego tekstu?

Jeśli jakiś użytkownik nie może uzyskać dostępu do polecenia sudo3 razy, należy to zgłosić użytkownikowi root w dziennikach dostępu \ błędach ..

Czy root może zobaczyć te próby (np. Wypróbowane hasła) w tekście w logach?

Nie, hasła nie są domyślnie rejestrowane. Byłby to problem z bezpieczeństwem, ponieważ dzienniki mogą być odczytywane przez innych administratorów, umożliwiając podszywanie się pod użytkownika w przypadku nieco błędnie wpisanego hasła.

Próby logowania zakończone powodzeniem i niepowodzeniem są logowane

/var/log/auth.log

Przykład udanej próby:

Oct 23 21:24:01 schijfwereld sudo: rinzwind : TTY=pts/0 ; PWD=/home/rinzwind ; USER=root ; COMMAND=/bin/bash
Oct 23 21:24:01 schijfwereld sudo: pam_unix(sudo:session): session opened for user root by (uid=0)

I nieudane:

Oct 23 21:25:33 schijfwereld sudo: pam_unix(sudo:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/1 ruser=rinzwind rhost=  user=rinzwind
Oct 23 21:26:02 schijfwereld sudo: rinzwind : 3 incorrect password attempts ; TTY=pts/1 ; PWD=/home/rinzwind ; USER=root ; COMMAND=/bin/bash

Rejestruje nieudaną próbę i rejestruje również łącznie 3 błędnie wpisane hasła.

Hasła do sudoprób nigdy nie są pokazywane ani przechowywane.

Zazwyczaj nie rejestruje się haseł używanych podczas prób logowania, nawet jeśli dane hasło było nieprawidłowe. Jest tak po prostu dlatego, że hasło może być ważne dla innego użytkownika w tym samym systemie (np. Użytkownik błędnie wpisał swoją nazwę użytkownika , a nie hasło) lub może być trywialną alternatywą rzeczywistego hasła (użytkownik pominął literę lub mniej więcej).

W obu przypadkach pozostawiłoby w systemie hasło w postaci zwykłego tekstu, podatne na wyciek niektórych informacji. (Hasło może być również prawidłowym hasłem dla innego systemu niż ten, na którym zostało wprowadzone, ale to naprawdę jest większy problem dla „ich”, a nie „nas”.)

Nieco związane z tym są przypadki, w których użytkownik zapisuje hasło zamiast nazwy użytkownika (np. Zwykle używa systemu, który automatycznie wprowadza nazwę użytkownika, ale teraz tego nie zrobił, ale nadal wpisał hasło jako pierwszą rzecz). W takim przypadku w dziennikach będzie znajdować się hasło w postaci zwykłego tekstu. Nie jest to optymalne, ale przeglądanie nazw użytkowników dla zwykłych nieudanych prób logowania jest przydatne i nie ma prostego rozwiązania do ich przechowywania, ale nie hasła wprowadzane jako nazwy użytkownika.

To powiedziawszy, nic nie stoi na przeszkodzie, aby administrator systemu zarejestrował również hasła. Dodanie rejestrowania można prawdopodobnie wykonać przez dodanie jednego wywołania syslog()i rekompilację modułu PAM. (PAM jest tym, z którego korzysta Ubuntu sudo, ale oczywiście to samo dotyczy aplikacji internetowych i wszystkiego innego.)

Więc nie, zwykle administrator nie widzi haseł wprowadzonych w systemie, ale jeśli wprowadzisz hasło w systemie, któremu nie ufasz, ściśle mówiąc, powinieneś uważać je za utracone i zmienić je.

Ogólniej mówiąc, bardzo niewiele programów w Uniksie kiedykolwiek zalogować rzeczywistych haseł do syslog lub gdzie indziej - nie ma prawie nigdy nie jest dobry powód, aby to zrobić, a istnieją powody stojące nie do.

Ze względu na sposób mieszania haseł system nie może odróżnić błędnego hasła od literówki - jeśli twoje hasło to% $ zDF + 02G i wpiszesz% $ ZDF + 02G, zawiedzie Cię tak mocno, jak to możliwe zrobiłby to, gdybyś wpisał „Rubberbabybuggybumpers”, ale zalogowanie nieudanego hasła dałoby cenne informacje złośliwemu podmiotowi trzeciemu czytającemu dziennik.

Jedyny przypadek znalazłem gdzie program nie ma zdolności do haseł logowania (i przypadek użycia gdzie że byłoby dobrym pomysłem) znajduje się w serwerach RADIUS, gdzie można w przełączniku pinch na więcej-informacji-than- prawdopodobnie potrzebny tryb debugowania, a następnie jawnie dodaj flagę oznaczającą „tak, w tym hasła”, ponieważ klient nie może się połączyć i musisz całkowicie wykluczyć każdą możliwą przyczynę ...