Hiding Passwords in Debug Output

[Alan DeKok]

"Garber, Neal" <Neal.Garber at energyeast.com> wrote:
> I agree with you 100% that having the server show what it is doing is
> very helpful when troubleshooting problems.  Can you help me understand
> how displaying the plaintext password tells me what the server is doing?

  How else do you know what the user entered for their password?

> Even though the password is hidden by encryption in many other
> protocols, it is possible to properly configure and troubleshoot
> FreeRadius for these protocols.  Are you saying you don't see any value
> in having the option to hide secret information?

  There's no need to ask such leading questions.

  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.

> Displaying the password while troubleshooting our
> FreeRadius deployment did not help me solve any problems.

  And that's the crux of the problem.  The server is used by people
other than you, who DO need access to that information.

> I'm open to the idea that it might help some people solve problems.
> But, if it's not normally needed and it's secret information, why
> not give administrators the option to suppress it (as the detail
> module does)?

  Why not simply run the shell script I presented?

  And the reason the "detail" files can suppress information is that
they get archived off-machine, where potentially others can see the
information.  And, the detail files did NOT suppress anything for the
longest time.

> What I'm saying is that displaying plaintext passwords and/or
> potentially storing them unencrypted on electronic media (e.g.,
> redirected output from FreeRadius that is stored on disk and in
> backups), increases the risk of user account compromise.

  Then don't re-direct them to disk, OR run the shell script I presented.

> Also, being a
> FreeRadius administrator does not imply that you are an administrator of
> the backend user database.  I'm not sure I understand the relevance of
> having permission to stop and start the server..

  Because then the administrator is probably root, and can just sniff
the network to get the packets, and read the config files to get the
shared secret, to decrypt the passwords.

> That's an excellent point - I could easily see that outcome.  Would you
> feel differently if the mask was different (e.g., "<password hidden by
> config. option>")? 

  No.

  Again, this "security" has near-zero value-add, and can be
implemented on your end by a simple shell script wrapper around the
server.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog