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

Re: Fwd: Password leaks are security holes



This one time, at band camp, Johan Walles said:
> 2008/8/28 Giacomo A. Catenazzi <cate@debian.org>:
> > Johan Walles wrote:
> >> Security shouldn't be based on nobody ever doing more or less common
> >> mistakes.
> >
> > auth.log was invented for this reason, and separated to standard log:
> > it should be readable only by root, because users do errors.
> 
> It's readable by anybody with physical access to the hardware.
> 
> Hard disks get stolen all the time [1], and on publicly accessible
> machines it's often possible to boot in runlevel 1 or from something
> other than the hard disk and access any files you like.  That's why
> the passwords in /etc/shadow are all hashed, rather than just being
> chmodded.

For a normal install, if someone has physical access, they have
the machine.  Pretending otherwise is a waste of time.  Even though
/etc/shadow is hashed, it's not all that difficult to run password
crackers against it, and with a reasonable amount of CPU, it doesn't
even take that long.  If the hashes were completely safe, /etc/shadow
could be 0644, right?

> > Anyway root already has the capability to view passwords
> > (i.e. by installing alternate login programs, sniffing tty, ...)
> 
> That doesn't mean Debian should *help* root doing that in a default
> install.  Security by default, anybody?

We have that.  We just don't (and can't) protect against someone stealing
the disk and mounting it on their machine and rummaging through the
filesystem.  If you want that, use encrypted filesystems.  Hopefully, you
understand that that can't be the default, though.

> > So auth.log should log usernames, so that users don't do
> > wrong assumption that password are not accessible by root!
> 
> I can see a point in logging *valid* usernames.  Logging invalid
> usernames (which aren't unlikely to actually be passwords) is a
> security risk.

I think it is also a very good way to notice a dictionary attack
against a service, as opposed to a user screwing up their password.

Arguing that users don't have to take any responsibility after they
divulge their password doesn't impress me all that much.  I'm not a
maintainer for the package in question, but I certainly wouldn't make
any changes based on that argument.
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

Attachment: signature.asc
Description: Digital signature


Reply to: