sudo: 3 incorrect password attempts - can root see the password in clear text?
up vote
17
down vote
favorite
If some user can't access some command with sudo
3 times, this should be reported to root user in access logserrors..
Can root see these attempts (like passwords tried) in text in the logs?
sudo password security
add a comment |
up vote
17
down vote
favorite
If some user can't access some command with sudo
3 times, this should be reported to root user in access logserrors..
Can root see these attempts (like passwords tried) in text in the logs?
sudo password security
4
Implicit assumption: root is not being evil. If root is already being evil when you try to log in, all bets are off.
– Joshua
Oct 24 at 14:33
It is trivial to configure something on most systems, but its not part of any default config I know of.
– PlasmaHH
Oct 25 at 8:35
2
Obligatory xkcd xkcd.com/838
– Joe
Oct 25 at 9:04
add a comment |
up vote
17
down vote
favorite
up vote
17
down vote
favorite
If some user can't access some command with sudo
3 times, this should be reported to root user in access logserrors..
Can root see these attempts (like passwords tried) in text in the logs?
sudo password security
If some user can't access some command with sudo
3 times, this should be reported to root user in access logserrors..
Can root see these attempts (like passwords tried) in text in the logs?
sudo password security
sudo password security
edited Oct 23 at 20:48
guntbert
8,874133067
8,874133067
asked Oct 23 at 18:44
S_Flash
1,003117
1,003117
4
Implicit assumption: root is not being evil. If root is already being evil when you try to log in, all bets are off.
– Joshua
Oct 24 at 14:33
It is trivial to configure something on most systems, but its not part of any default config I know of.
– PlasmaHH
Oct 25 at 8:35
2
Obligatory xkcd xkcd.com/838
– Joe
Oct 25 at 9:04
add a comment |
4
Implicit assumption: root is not being evil. If root is already being evil when you try to log in, all bets are off.
– Joshua
Oct 24 at 14:33
It is trivial to configure something on most systems, but its not part of any default config I know of.
– PlasmaHH
Oct 25 at 8:35
2
Obligatory xkcd xkcd.com/838
– Joe
Oct 25 at 9:04
4
4
Implicit assumption: root is not being evil. If root is already being evil when you try to log in, all bets are off.
– Joshua
Oct 24 at 14:33
Implicit assumption: root is not being evil. If root is already being evil when you try to log in, all bets are off.
– Joshua
Oct 24 at 14:33
It is trivial to configure something on most systems, but its not part of any default config I know of.
– PlasmaHH
Oct 25 at 8:35
It is trivial to configure something on most systems, but its not part of any default config I know of.
– PlasmaHH
Oct 25 at 8:35
2
2
Obligatory xkcd xkcd.com/838
– Joe
Oct 25 at 9:04
Obligatory xkcd xkcd.com/838
– Joe
Oct 25 at 9:04
add a comment |
4 Answers
4
active
oldest
votes
up vote
34
down vote
accepted
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.
add a comment |
up vote
25
down vote
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)
And unsuccessful:
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
It logs the failed attempt and logs also the total of 3 wrongly typed passwords.
Passwords for sudo
attempts are never shown or stored.
4
The only way passwords are logged are usually when you forgot to hit enter after the username. So you log in as "Scott Tiger" instead of user Scott with password Tiger
– Lenne
Oct 24 at 17:14
But that's not sudo's fault ;-)
– Rinzwind
Oct 25 at 8:34
@Lenne when that happens to me (or otherwise when I absent mindedly type my password instead of a command), I delete the offending line from the shell history.
– Zanna
Nov 20 at 15:34
add a comment |
up vote
3
down vote
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.
add a comment |
up vote
0
down vote
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...
add a comment |
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
34
down vote
accepted
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.
add a comment |
up vote
34
down vote
accepted
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.
add a comment |
up vote
34
down vote
accepted
up vote
34
down vote
accepted
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.
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.
answered Oct 23 at 19:00
vidarlo
8,02542341
8,02542341
add a comment |
add a comment |
up vote
25
down vote
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)
And unsuccessful:
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
It logs the failed attempt and logs also the total of 3 wrongly typed passwords.
Passwords for sudo
attempts are never shown or stored.
4
The only way passwords are logged are usually when you forgot to hit enter after the username. So you log in as "Scott Tiger" instead of user Scott with password Tiger
– Lenne
Oct 24 at 17:14
But that's not sudo's fault ;-)
– Rinzwind
Oct 25 at 8:34
@Lenne when that happens to me (or otherwise when I absent mindedly type my password instead of a command), I delete the offending line from the shell history.
– Zanna
Nov 20 at 15:34
add a comment |
up vote
25
down vote
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)
And unsuccessful:
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
It logs the failed attempt and logs also the total of 3 wrongly typed passwords.
Passwords for sudo
attempts are never shown or stored.
4
The only way passwords are logged are usually when you forgot to hit enter after the username. So you log in as "Scott Tiger" instead of user Scott with password Tiger
– Lenne
Oct 24 at 17:14
But that's not sudo's fault ;-)
– Rinzwind
Oct 25 at 8:34
@Lenne when that happens to me (or otherwise when I absent mindedly type my password instead of a command), I delete the offending line from the shell history.
– Zanna
Nov 20 at 15:34
add a comment |
up vote
25
down vote
up vote
25
down vote
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)
And unsuccessful:
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
It logs the failed attempt and logs also the total of 3 wrongly typed passwords.
Passwords for sudo
attempts are never shown or stored.
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)
And unsuccessful:
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
It logs the failed attempt and logs also the total of 3 wrongly typed passwords.
Passwords for sudo
attempts are never shown or stored.
edited Nov 20 at 15:32
Zanna
49k13123234
49k13123234
answered Oct 23 at 19:27
Rinzwind
201k26385517
201k26385517
4
The only way passwords are logged are usually when you forgot to hit enter after the username. So you log in as "Scott Tiger" instead of user Scott with password Tiger
– Lenne
Oct 24 at 17:14
But that's not sudo's fault ;-)
– Rinzwind
Oct 25 at 8:34
@Lenne when that happens to me (or otherwise when I absent mindedly type my password instead of a command), I delete the offending line from the shell history.
– Zanna
Nov 20 at 15:34
add a comment |
4
The only way passwords are logged are usually when you forgot to hit enter after the username. So you log in as "Scott Tiger" instead of user Scott with password Tiger
– Lenne
Oct 24 at 17:14
But that's not sudo's fault ;-)
– Rinzwind
Oct 25 at 8:34
@Lenne when that happens to me (or otherwise when I absent mindedly type my password instead of a command), I delete the offending line from the shell history.
– Zanna
Nov 20 at 15:34
4
4
The only way passwords are logged are usually when you forgot to hit enter after the username. So you log in as "Scott Tiger" instead of user Scott with password Tiger
– Lenne
Oct 24 at 17:14
The only way passwords are logged are usually when you forgot to hit enter after the username. So you log in as "Scott Tiger" instead of user Scott with password Tiger
– Lenne
Oct 24 at 17:14
But that's not sudo's fault ;-)
– Rinzwind
Oct 25 at 8:34
But that's not sudo's fault ;-)
– Rinzwind
Oct 25 at 8:34
@Lenne when that happens to me (or otherwise when I absent mindedly type my password instead of a command), I delete the offending line from the shell history.
– Zanna
Nov 20 at 15:34
@Lenne when that happens to me (or otherwise when I absent mindedly type my password instead of a command), I delete the offending line from the shell history.
– Zanna
Nov 20 at 15:34
add a comment |
up vote
3
down vote
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.
add a comment |
up vote
3
down vote
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.
add a comment |
up vote
3
down vote
up vote
3
down vote
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.
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.
answered Oct 24 at 17:53
ilkkachu
1,021210
1,021210
add a comment |
add a comment |
up vote
0
down vote
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...
add a comment |
up vote
0
down vote
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...
add a comment |
up vote
0
down vote
up vote
0
down vote
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...
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...
answered Oct 25 at 7:39
Shadur
1416
1416
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1086498%2fsudo-3-incorrect-password-attempts-can-root-see-the-password-in-clear-text%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
4
Implicit assumption: root is not being evil. If root is already being evil when you try to log in, all bets are off.
– Joshua
Oct 24 at 14:33
It is trivial to configure something on most systems, but its not part of any default config I know of.
– PlasmaHH
Oct 25 at 8:35
2
Obligatory xkcd xkcd.com/838
– Joe
Oct 25 at 9:04