SMTP Password Stored as Plaintext

[putyourlightson]

Description

The SMTP password is stored as plaintext in the systemsettings table of the database. While being able to read and use this password is obviously required for Craft to send emails over authenticated SMTP, shouldn't it be hashed or encrypted?

Additional info

• Craft version: 3.0.0-beta.26

[michaelrog]

Probably, although I can't think of a way to encrypt it that couldn't be easily reversed by someone with access to the database. (I don't remember if the system encryption key is stored in the db; If not, encrypting settings would at least be useful for securing sensitive info at rest in db backups/snapshots.)

In any case, the mailer component can be customized by config, which makes it easy to keep stuff like passwords/keys in env vars and out of the database.

[putyourlightson]

Agreed, it would realistically be obfuscation over encryption, however with an encryption key stored in the config file, any unauthorised database access (or db backups) would not compromise the sensitive password. Yii2 supports encryption/decryption of course so it would simply require some implementation in Craft.

Storing the mailer settings in the config file offers some level of protection but it will still be in plaintext and it limits customisation of the mailer settings.

[brandonkelly]

We can’t hash the password without an encryption key. The one Craft auto-generates and places in storage/runtime/validation.key is not considered reliable enough to hash permanent DB-stored data with. And requiring users to supply their own validation key with the validationKey config setting is just as much work as having them set their email password directly in config/app.php, so there’s not really an advantage to that.

[putyourlightson]

requiring users to supply their own validation key with the validationKey config setting is just as much work as having them set their email password directly in config/app.php

Perhaps, but the advantage of a secure validationKey is that it can then be used by plugins to encrypt any sensitive data that they might store in the database. This is actually why I brought this issue up in the first place. I have created a custom mailer for a plugin and would like to encrypt the sensitive settings that are stored in the database and that should not be stored as plaintext. Yes, I can manage the encryption myself but it seems to make sense to me that if a validationKey exists that it be secure enough to use for data encryption.

[brandonkelly]

We’re thinking maybe we can solve the unreliableness of the validation key, by doing a better job of encouraging people to define one in their config (or better yet, their .env file). If we do that, then we’ll be more open to using it for things like encrypting email passwords.

[putyourlightson]

Cool, any reason that the validation key can't be made reliable by default in Craft 3?

[brandonkelly]

Nope, that’s what we’re looking into.

[putyourlightson]

These commits are looking good so far :)

[jedie]

i noticed that the smtp password is stored crypted in version v3.0.36
But in the new v3.1.1 it is stored in plaintext.

When updating from 3.0 to 3.1 you can see the raw base64 string in the admin. If i change the password, then it's in plaintext and it's plaintext in a new created sql dump.

I found in https://github.com/craftcms/cms/blob/develop/CHANGELOG-v3.md#310---2019-01-15 a related entry:

Some Site settings (Base URL), volume settings (Base URL and File System Path), and email settings (System Email Address, Sender Name, HTML Email Template, Username, Password, and Host Name) can now be set to environment variables using a $VARIABLE_NAME syntax. (#3219)

So it's maybe related to: #3219 ?!?

[putyourlightson]

Becuase this is an autosuggest field that supports environment variables, I'm guessing it has to be a plaintext field. Probably best to use and environment variable to protect the password.

[jedie]

Hm, okay... I think it's a step backwards to the solution before this issues was closed, isn't it?
Now I only have two choices:

• I save the password in plaintext in the admin and so it is also in plaintext in the sql dump.
• or I save it in plaintext in the .env file and a $VARIABLE_NAME in admin.

And what's the way to migrate? As i've written: after v3.0 -> v3.1 update i see a base64:... string in the form field... Will this base64 string be converted in memory? So no changes are actually needed? Or do I have to enter the password again so that it is stored in plain text?

[brandonkelly]

i noticed that the smtp password is stored crypted in version v3.0.36

That was never the case.

Before 3.1, SMTP passwords were encrypted within the Email settings form UI just to make it harder to quickly learn them just by going to the Email settings page and copying the input value. But they were still stored in plain text in the database.

That situation was made worse by project configs, because now the password isn’t just stored in plain text in the database, but also potentially in your project.yaml file, and then committed to Git.

So that and other sensitive fields is the reason we added support for environmental settings (#3219), where you can enter an environment variable name into the field input, and that variable name is what gets stored in the DB and project.yaml.

We technically could have continued to encrypt the current SMTP password value in the UI if it’s not set to an environment variable, and we considered that, but decided against it because it’s better to make it painfully obvious that the password is stored in plain text so people address it, rather than give them a false illusion of security.