Re: Password leaks are security holes
It is not often that I post but
1) Logging invalid usernames which can be used to detect all manor of
attacks including dictionary username attacks and password brute force
2) As pointed out earlier the file is root only access. The argument
that can be read if you physical access to the box. Physical access to
the box gives you numerous methods of obtaining passwords including
installing key loggers and stealing ssh keys. Once somebody has root on
your box either through physical access or otherwise, I would be more
concerned with all the other information they could have stolen which
would give the game away. E.G. date of birth from emails or passwords
to supposedly secure systems from stored emails. Going through a log of
failed user attempts is going to be high hanging fruit.
3) If you are typing in your password as a username by mistake chances
are you should change it immediately. It has probably been in the
clear on the monitor at best and you could have been shoulder surfed. I
guess you could be in a room with no one around but this should not be
assumed. The username is also likely to be stored on remote machines
for example in a bash history.
4) If this kind of error really concerns you move to a properly secure
password system. Passwords are severely limited in many well documented
ways. For a kickoff people can only remember so many password and
therefor tend to write them down or use the same password for multiple
accounts. Some sort of one time password system or certificate based
system is probably the way to go.
5) A skilled administrator could use logging of failed user attempts as
a way of detecting people entering a password as a username. This could
then be used trigger for appropriate training or ensure that the
password is changed. Example user contacts administrator to say they
can't log into service administrator realizes that they are using the
password instead of username. Administrator is able to fix issue and
then either force or instruct user to change password.
6) It is an useful forensic feature. Clueless admin/user sets up server
with rubbish password. Hacker/Cracker gets into account. Assuming
Auth.log isn't cleaned (sometimes a bit assumption if they have got
root) you can often establish vector of attack by fail logins.
I agree it is a potential weakness but on the balance and attack vector
but on balance I would rather have the feature there by default.
Reasons 1 and 5,6 however make this a feature worth having on by default
for me and I think the risks are very minor in comparison to the benefits.
I could see the point of disabling this on default for home user who
never checks logs but Debian used more as a server operating system (I
know there are derivatives that are more workstation orientated). If
you are using Debian as a Workstation chances are their are many easier
places to steal passwords from such as application configuration files
(e.g. gaim, mozilla and firefox).
Johan Walles wrote:
severity 311772 critical
tag 311772 + security
When users' clear text passwords are logged, that's a security hole.
Setting severity to critical since this bug "introduces a security
hole on systems where you install the package". Quote is from the
definition of the critical severity at
Tagging with security because "This bug describes a security problem
in a package". Quote is from definition of "security" tag at