Password field is insecure

i agree.

Thirded.

I could maybe settle for a hide password check box.

Second that

What would be gained from an encrypted password? If I already have access to the database, I can easily retrieve the salt used and decrypt the password. Changing the field type sounds ok, though.

This is a discussion which has been entertained endlessly for other applications. Basically, encrypting the password only prevents that an admin will accidentally learn your password. So you can argue encryption gives a false sense of security.

However, Drupal stores user passwords encrypted (in the 'pass' field of the 'user' table). So IMHO, smtp should follow that example and use encryption for the password and an appropriate html form element.

Yup.

Drupal uses a one-way hash on its password field. This is fine because it can simply hash passwords from the login form and match it against the stored hash. There is no reason Drupal needs to know the user's plain text password.

However, the SMTP password is used by Drupal to authenticate with a third party (SMTP server) so if you want to encrypt it you'd need to use a reversible encryption (mcrypt etc) to decrypt it before use. Since the decryption keys would have to be available to Drupal, anyone who has access to the Drupal files and database would also be able to decrypt the encrypted passwords. In other words, this would only add protection from people who have access to the database but do not have access to the Drupal files. Also, true reversible encryption requires PHP extensions which may not be installed on many hosts.

Yes, the difference to user passwords is that typed in user passwords are also hashed before validation against the stored password. To be future-proof, SMTP module must not store the configured authentication credentials, so they can be encrypted/hashed on demand for SMTP servers that only support certain AUTH methods.

Additionally, site builders should be able to easily place SMTP credentials into settings.php.

Sounds like there are two separate issues here:

• that a password form field should be used on the admin page to prevent over-the-shoulder reading of the password.
• that the password is stored in the database in plain-text

The second doesn't block the first, does it?
Is there anything wrong with the simple change in the patch attached? It just makes the password field a real password field...

(If "false sense of security" is an issue, maybe a warning can be provided...)

This is good enough for now. Great work!

To be included in the next version?