sudo: 3 попытки неправильного пароля - корень может видеть пароль в открытом тексте?

Попытки входа в систему, успешные и неудачные, регистрируются в

/var/log/auth.log

Пример успешной попытки:

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)

И неудачные попытки:

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

Он регистрирует неудачная попытка и регистрирует также 3 неверно введенных пароля.

Пароли для sudo попыток никогда не отображаются и не сохраняются.

В общем, очень очень немногие программы в Unix когда-либо регистрируют реальные пароли в системном журнале или где-либо еще - почти никогда нет веских причин для этого, и есть веские причины , не ] к.

Из-за способа хеширования паролей система не может определить разницу между неправильным паролем и опечаткой. Если ваш пароль был% $ zDF + 02G, и вы ввели% $ ZDF + 02G, он потерпит неудачу как трудно, как если бы вы набрали «rubberbabybuggybumpers», но регистрация неудачного пароля выдаст ценную информацию злонамеренной третьей стороне, читающей журнал.

Один случай, который я обнаружил, когда программа имела возможность регистрировать пароли (и случай использования, где это было бы неплохо), находится на серверах RADIUS, где вы можете в переведите переключатель в режим отладки «больше информации, чем вы, вероятно, хотели», а затем явно добавьте флаг, который означает «да, включая пароли», потому что у вас не удается подключиться к клиенту, и вам нужно исключить абсолютно все возможные причины ...

Обычная практика не должна регистрировать пароли, используемые в попытках входа в систему, даже если бы рассматриваемый пароль был неверным. Это просто, потому что пароль мог бы быть действительным для другого пользователя в той же системе (например, пользователь ввел с опечаткой их имя пользователя, не пароль), или могло бы быть тривиальное чередование фактического пароля (пользователь пропустил приблизительно одну букву).

Любой из тех случаев оставил бы наложение незашифрованного пароля в системе, уязвимой для некоторой информационной утечки. (Пароль мог бы также быть действительным паролем для некоторой другой системы, чем та, которая в это ввели, но это - действительно больше проблемы для "них", не "нас".)

Несколько связанный с этим случаи, где пользователь пишет их пароль вместо их имени пользователя (например, они обычно используют систему, которая вводит имя пользователя автоматически, но теперь не сделала, но все еще ввела пароль как первую вещь). В этом случае у Вас был бы незашифрованный пароль в журналах. Это не оптимально, но наблюдение, что имена пользователей для обычных неудавшихся попыток входа в систему полезны, и нет никакого простого решения для хранения их, но не паролей, введенных как имена пользователей.

Тем не менее нет, ничто, чтобы мешать администратору системы иметь систему не регистрирует пароли, также. Добавление входа могло, вероятно, быть сделано путем добавления одного вызова к syslog() и перекомпиляция модуля PAM. (PAM, являющийся, что Ubuntu и sudo используйте, но конечно то же касается веб-приложений и всего остального, также.)

Так, нет, обычно администратор не видит, что пароли ввели в систему, но если Вы вводите свой пароль в системе, Вы не доверяете, необходимо, строго говоря, полагать, что это проиграло, и измените его.