Hiding Passwords in Debug Output
Garber, Neal
Neal.Garber at energyeast.com
Tue Sep 26 16:37:33 CEST 2006
> The administrator has access to ALL secret information by simple
> fact that he's an administrator. He can run tcpdump, and manually
> decrypt the passwords. So hiding the password on the server is
> pointless, and a waste of time.
I realize that. I wasn't trying to *prevent* the admin. from getting
the password if they felt they needed it (as if the admin. couldn't be
trusted). Rather, I believe most of the time admins don't need to see
it so why not have the *option* to suppress it since it's considered
sensitive information. Displaying it increases the risk that others
could see it and/or that an admin. would redirect debug output to disk
because: they forgot it included sensitive information, they don't
understand the risk, they're troubleshooting an intermittent problem and
they need to save the output for later analysis, or because they
normally redirect output of the server to disk just in case they need to
troubleshoot a problem. Once it's on disk, it's the same issue that
caused the eventual change to the detail module.
> And that's the crux of the problem. The server is used by people
> other than you, who DO need access to that information.
That's unfair Alan. I was not trying to *dictate* that other admins
shouldn't see it - I was proposing that admins should have a choice -
because, IMO it's not needed to troubleshoot most problems.
> Why not simply run the shell script I presented?
I could and it would do most of what I wanted. However, it feels like a
kludge and everyone on my team would need to remember to filter the
output when running in debug mode. I just think it's safer (from the
perspective of admins that don't want/need to see the passwords) to have
a config. option that forces the suppression. With the config. option,
you can change the server to run in debug mode without having to
remember to pipe the output to sed (or to run a special script that
pipes the output to sed).
I've tried to articulate my point of view and why I see value in having
this option. I've asked questions in an attempt to understand your
point-of-view and you didn't answer them. I feel either I failed to
explain myself clearly or you made up your mind from the start and
aren't interested in hearing contrary opinions. Perhaps our difference
is a matter of perspective, level of paranoia and the business
environment in which the server is operating. In any case, it's not
worth arguing about. After all, FreeRadius is open source so, if my
team feels strongly enough about it, we can make the change and maintain
it locally.
More information about the Freeradius-Users
mailing list