• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Item4587: SMTP password is in cleartext in LocalSite.cfg (hidden in configure)

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Engine   Normal No Action Required   n/a  

Edit Form Data

Reported By:
Applies To:
Current State:
Waiting For:
Target Release:
Released In:


When an SMTP password is required for sending mail, that password is stored in cleartext in LocalSite.cfg.

That is not a good idea at all!

Marked as Urgent because of the security risk this entails.

-- TWiki:Main/ThomasWeigert - 08 Sep 2007

Discussed previously in Item2352.

I am really bad at security issues, but if an attacker gains filelevel access to your machine don't you have other and worse problems? Second, if we choose to encrypt the password won't we need to share the key to decrypt it anyway?

Probably others are better at seeing the right solution to this, please step in.

-- TWiki:Main.SteffenPoulsen - 08 Sep 2007

It is never a good idea to have your password in cleartext. Here one particular users password has to be exposed, and the file is readable by everyone. So everybody who can read this file can log in as this user on the machine that is the smtp host, or at least, access the users mail account.

This is problem in particular as the smtp host may be another machine that we do not have control over (e.g., if a "smart" MTA is used) so we might not be able to make up a user just for the purpose of mailing. Thus this might have to be the email id of a real person, who might not want his or her mail login exposed (and often this mail login would also be his or her real login; in our case, it would be my site wide password).

That level of access might tempt even normal users, not even speaking of somebody who had gained access to the system. In fact it is worse than having access to this system, as there might be nothing of value on this system, but there might be value to be gained from having my password far beyond what can be done to this one system.

-- ThomasWeigert - 08 Sep 2007

So, can you think of a practical solution to the problem we could pursue?

-- TWiki:Main.SteffenPoulsen - 08 Sep 2007

Like you I am not familiar with this area sufficiently to give guidance.

I read through Item2352. There it is claimed a solution has been implemented in 4.0.3. I cannot see this solution having taken care of this problem, as I can see the password clearly.

-- ThomasWeigert - 08 Sep 2007

You can see it clearly in configure?

-- TWiki:Main.SteffenPoulsen - 08 Sep 2007

No. I can see it clearly in lib/LocalSite.cfg

Any user on the system can see my password!

On data entry the password is hidden, but then it is stored in cleartext in the config file, as I described earlier.

-- ThomasWeigert - 09 Sep 2007

No, any user can not read the password, that is just plain wrong. Use the usual file system tools available and set permissions so only the apache user gets to read the file - configure will not change permissions on the file between runs.

Better solutions to this problem could include:

  • establishing some other kind of trust between the systems (SMTP / machine-to-machine trust - AD/Kerberos/LDAP/TCP wrappers/etc)
  • using a non-sensitive password for the connection (SMTP-privileges only)
  • running a local smtp proxy / smarthost that will receive regular smtp locally and forward with auth (although here you will face the same problem - where should the daemon store the password?)

The solution as I see it does not involve having TWiki setting up an encrypted keychain with a password that needs to be manually entered at boot time / hardware token that needs to be available - or other initiatives in that direction.

-- TWiki:Main.SteffenPoulsen - 09 Sep 2007

Steffen, the default setting of LocalSite.cfg is so that everybody can see the password, as it is u+rw g+r o+r. At a minimum, we would have to change the default setting to go-r. In this situation, only the daemon (and those who have superuser privileges) can read the password.

Note that this still leaves a password open to be read by others, in this case those who have superuser rights. Note that this might be a password of a different system that those who have superuser rights for this machine would normally not have rights to. So we are exposing information that is both sensitive and not normally accessible to those who it is exposed to.

Not knowing about the intricacies of this, I am surprised that the authentication process with the mail host would require the password in cleartext. Are we sure we could not store the password encrypted and authenticate that way? Similar to how passwords are stored in .htpasswd or /etc/passwd?

Or another thought: Think of, for example, Outlook. Your authentication password is stored somewhere. If that would be in cleartext or easily decipherable (such as by a known key or a key easily accessible, then I would expect that this information would have already been made public. Given that it is not, there must be some way of storing passwords in a way that they are not accessible, but can be used for mail authentication.

Your solution above all seem to require additional rights that a twiki administrator does not have or architectural choices on the network that the twiki administrator might not have open to him or her.

-- ThomasWeigert - 09 Sep 2007

The RFC for smtp auth is at http://tools.ietf.org/html/rfc2554, an example of the negotiation at http://www.technoids.org/saslmech.html.

Outlook uses Windows' own "Protected Storage System Provider" implemented in the registry. Other systems uses different forms of "wallets", "vaults", "private storage", etc - usually something that opens up once you authenticate against it in some way (logging into Windows for the PSSP).

I have created Item4593 on restricting LocalSite.cfg at creation time; lowering this to normal. Ideally it should be changed into an enhancement request on a "TWiki-wallet" and discussed further in Codev.

-- TWiki:Main.SteffenPoulsen - 09 Sep 2007

When you store a password it is easy to store an encrypted version and you can use very strong one-way encryption. You never decrypt a password. When you authenticate you encrypt the entered password and compare the result with the stored encrypted password.

In this case we have to send a password to an SMTP server. We cannot know if it uses encrypted passwords or which key is uses if it does.

We can encrypt the password and store it but we will have to decrypt it before we use it for authentication.

And then anyone can decrypt it using the code in our open source TWiki. Ie. it is not safe at all.

Thomas - in your environment - which is same as mine - you should not need user name and password stored to send emails.

And for those that need it - the right approach is to setup an email user only for this purpose. And yet still secure the files on the server so not anyone can access the files. I would also limit the access to the server to only a handfull of admins.

Home users will not worry much either. They are the only ones with login access to the server. And it is often those that will need an SMTP password because public SMTP servers today need authentication to avoid spammers.

I have a hard time to find a secure method to store the password for an SMTP server using encryption and decryption with a cypher in the same open source code.

-- TWiki:Main.KennethLavrsen - 10 Sep 2007

It is a common misunderstanding, that an encrypted version of the password is stored. This is usually not the case - instead you just store a hash and compare this hash against the hash of a candidate (using MD5 / SHA-1 or similar algorithms).

-- TWiki:Main.SteffenPoulsen - 11 Sep 2007

To the best of my knowledge there is no way to make this secure, which is why I stored the pw in plaintext in the first place.

Make sure your LocalSite.cfg is secured so that no-one but the webserver user can read/write it.

No action.


Summary SMTP password is in cleartext in LocalSite.cfg (hidden in configure)
ReportedBy TWiki:Main.ThomasWeigert
Codebase 4.1.2
SVN Range TWiki-4.2.0, Sat, 08 Sep 2007, build 14780
AppliesTo Engine

Priority Normal
CurrentState No Action Required


TargetRelease n/a

Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r13 - 2007-09-16 - CrawfordCurrie
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback