close
Comments you submit will be routed for moderation. If you have an account, please log in first.
Modify

Opened 6 months ago

Closed 6 months ago

#562 closed enhancement (fixed)

Please no Passwords in Logfiles

Reported by: opiopi Owned by: tboeckel
Priority: normal Milestone: YAM 2.10
Component: coding/memory Version: nightly build
Severity: minor Keywords:
Cc: OS Platform: All
Blocked By: Blocking:
Release Notes:

Description

I just send a mail with the debug version of YAM an saw my password into the logfile. IMHO it's not really required and a big security hole to include the password in plain or base64 encoded form and should be replaced with someting like xxx. The lines are:
smtp.c:1006:prepared AUTH LOGIN challenge: 'MyOffCurseNotWorkingPasswort'
smtp.c:1018:encoded AUTH LOGIN challenge: 'TXlPZmZDdXJzZU5vdFdvcmtpbmdQYXNzd29ydA=='
don't try the password it's really not working because it's changed.
A user who want to debug has the debug argument YAM which show the password in base64 encoded form.

used version:
YAM 2.10-dev (09.05.2014)
Copyright (C) 2000-2014 YAM Open Source Team [OS3/m68k, r7846]

Attachments (0)

Change History (8)

comment:1 Changed 6 months ago by tboeckel

  • Milestone set to YAM 2.10
  • Priority changed from undecided to normal
  • Severity changed from major to minor
  • Status changed from new to accepted

comment:2 Changed 6 months ago by damato

Let me comment on that report here:

  1. First of all, we always stated in the past that sent in log files should always be checked to not contain any private or security relevant data. This won't change with changing that particular debug lines you reported because there might be hundreds of other things that users don't want to see in public posted here. Bottom line: It is always the responsibility of each user to check any files for private things before upload them here.
  2. There are situation where we (the developers) need to have debugging statements in YAM which output passwords or any other private information because we need to test these situations as well.
  3. Nevertheless, I fully support making sure to try to expose as less as possible things via the debug output.

To summary on the above:

I think a proper fix/change would be to introduce a new "PASSWD" or "PRIVATE" debug group which is disabled per default and which should always be used on debug statements potentially exposing private user information. By doing that instead of simply removing these debug statements we can take care of point (1) and (2) from above while at the same time taking care of the privacy of our users. Of course this debug statement should be disabled per default and if it is enabled we could even output a huge warning in the header of the debug output so users are notified and can make sure to NOT using the PRIVATE debug statements.

Simply listing and removing debug statements wouldn't help really.

comment:3 Changed 6 months ago by tboeckel

Jens, while I agree with the idea of a new debug class in principle I think it is still too much danger to included plain text passwords in a debug place, even if this requires specific interaction by the user. We already obfuscated the passwords for POP3 transfers and I think we should do the same for SMTP transfers. There is no point in having a user's password in a log file for us developers. All we need to know is the fact that the password gets sent at all. It is the user's responsibility to enter a correct password. We don't need to know it. For the AUTH PLAIN login type we don't have any debug output either.

Hence I suggest to change the two mentiones lines in such a way that the password is omitted, but the general output remains.

comment:4 Changed 6 months ago by damato

Well, i agree of course that we don't need passwords in clear text, but there might be situations where password information might be converted to something like base64 and output for debugging reasons and thus be easily be converted to plain text. Such situations might be hardly catchable. In addition, there might be other privacy related information (not passwords) that should not be visible. For such purposes ot would be good to have such a PRIVATE debug class which could be used for such cases wheb actually developing.

comment:5 Changed 6 months ago by tboeckel

And how do you want to make sure that such private data does not occur by accident in arbitrary debug statements? We have debug classes like DBC_TIMER or DBC_TRACE, but these require special macros to be called.

For the SMTP case we just have to change 2 lines. That's all...

comment:6 Changed 6 months ago by opiopi

What about a ENV variable like the one already used "I_KNOW_YAM_IS_UNDER_DEVELOPMENT" but named i.e. "YES_INCLUDE_PASSWORDS_IN_LOGFILES" or something like this? And only if the variable is true then include the passwords into the logfile.

comment:7 Changed 6 months ago by tboeckel

  • Owner set to tboeckel
  • Status changed from accepted to assigned

comment:8 Changed 6 months ago by tboeckel

  • Resolution set to fixed
  • Status changed from assigned to closed

In 7910:

  • tcp/smtp.c: removed the plain text and encoded password from the debug log. This closes #562.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber

  • Frank Weber(Reporter, Participant)
  • Thore Böckelmann(Owner, Participant)