[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 attacks.

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

  Regards //Johan

Reply to: