No, passwords are not logged by default. This would be a security problem, as logs may be read by other administrators, allowing impersonation of the user in case of a slightly mistyped password.
Login attempts successful and unsuccessful are logged in
/var/log/auth.log
Example of a successful attempt:
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)
The usual practice is to not log passwords used in login attempts, even if the password in question was invalid. This is simply because the password might be valid for another user on the same system (e.g. the user mistyped their username, not the password), or might be a trivial alternation of the actual password (the user missed a letter or so).
Either of those cases would leave a plaintext password laying on the system, vulnerable to some information leak. (The password might also be a valid password for some other system than the one it was entered on, but that's really more of a problem for "them", not "us".)
Somewhat related to this is the cases where a user writes their password in place of their username (e.g. they usually use a system that enters the username automatically, but now didn't, but still typed the password as the first thing). In that case, you would have a plaintext password in the logs. This is not optimal, but seeing the usernames for the usual failed login attempts is useful, and there's no simple solution for storing them but not passwords entered as usernames.
That said, there's nothing to stop the administrator of the system from having the system log the passwords, too. Adding the logging could probably be done by adding one call to syslog() and recompiling the PAM module. (PAM being what Ubuntu and sudo use, but of course the same applies for web apps and everything else, too.)
So, no, usually an administrator can't see the passwords entered on the system, but if you enter your password on a system you don't trust, you should, strictly speaking, consider it lost and change it.
More generally speaking, very few programs in unix ever log actual passwords into syslog or elsewhere -- there's almost never a good reason to do so, and there are good standing reasons not to.
Because of the way passwords are hashed, the system can't tell the difference between a wrong password and a typo - If your password was %$zDF+02G and you typed %$ZDF+02G it'll fail you as hard as it would if you typed 'rubberbabybuggybumpers', but logging the failed password would give valuable information away to a malicious third party reading the log.
The one case I've found where a program did have the capability to log passwords (and a use case where that'd be a good idea) is in RADIUS servers, where you can in a pinch switch on more-information-than-you-probably-wanted debug mode and then explicitly add the flag that means 'yes, including passwords' because you've got a client failing to connect and you need to rule out absolutely every possible cause...
No, passwords are not logged by default. This would be a security problem, as logs may be read by other administrators, allowing impersonation of the user in case of a slightly mistyped password.
Login attempts successful and unsuccessful are logged in
Example of a successful attempt:
And unsuccessful:
It logs the failed attempt and logs also the total of 3 wrongly typed passwords.
Passwords for
sudo
attempts are never shown or stored.The usual practice is to not log passwords used in login attempts, even if the password in question was invalid. This is simply because the password might be valid for another user on the same system (e.g. the user mistyped their username, not the password), or might be a trivial alternation of the actual password (the user missed a letter or so).
Either of those cases would leave a plaintext password laying on the system, vulnerable to some information leak. (The password might also be a valid password for some other system than the one it was entered on, but that's really more of a problem for "them", not "us".)
Somewhat related to this is the cases where a user writes their password in place of their username (e.g. they usually use a system that enters the username automatically, but now didn't, but still typed the password as the first thing). In that case, you would have a plaintext password in the logs. This is not optimal, but seeing the usernames for the usual failed login attempts is useful, and there's no simple solution for storing them but not passwords entered as usernames.
That said, there's nothing to stop the administrator of the system from having the system log the passwords, too. Adding the logging could probably be done by adding one call to
syslog()
and recompiling the PAM module. (PAM being what Ubuntu andsudo
use, but of course the same applies for web apps and everything else, too.)So, no, usually an administrator can't see the passwords entered on the system, but if you enter your password on a system you don't trust, you should, strictly speaking, consider it lost and change it.
More generally speaking, very few programs in unix ever log actual passwords into syslog or elsewhere -- there's almost never a good reason to do so, and there are good standing reasons not to.
Because of the way passwords are hashed, the system can't tell the difference between a wrong password and a typo - If your password was %$zDF+02G and you typed %$ZDF+02G it'll fail you as hard as it would if you typed 'rubberbabybuggybumpers', but logging the failed password would give valuable information away to a malicious third party reading the log.
The one case I've found where a program did have the capability to log passwords (and a use case where that'd be a good idea) is in RADIUS servers, where you can in a pinch switch on more-information-than-you-probably-wanted debug mode and then explicitly add the flag that means 'yes, including passwords' because you've got a client failing to connect and you need to rule out absolutely every possible cause...