4

As responsible admins we know of common weaknesses like

But how do we deal with this in practice?

Of course with technologies like passwordless authentication via SSH and tools like sudo, it is possible to get rid of stored login credentials in important places and this really helps during automated deployment of Linux servers.

But as soon as you leave the operating system and install applications, chances are high that you are confronted with the issue where to securely store the passwords.

For example if you install a database server, most likely you need to save the cleartext password to a configuration file of your web application.

Then you should secure the configuration file so that only the admin is able to view the credentials and you should limit the access permissions of the database user in order to limit the possible security impact.

But how to deal with e.g. the main administrative database account? At least your dbas should know it (so you need somewhere the cleartext) and as OS admin you should not know the credentials. Or the deployment is done by devops and they should not know any of the credentials on production servers.

Possible solutions

After thinking this through for a longer period of time, I come up with three possible solutions but they have weaknesses of their own:

  1. Generate random credentials during deployment and store it in a database in a write once fashion. And e.g. dbas have another user that may read only database credentials. But how to deal with cleartext passwords in configuration files of e.g. webapps? A root user could read them. Also the root user of the password database could possibly read all password credentials.

  2. Accept cleartext passwords and default credentials during deployment and add a postscript that changes any and all passwords. Maybe even interactive where authorized people have to enter the credentials during runtime of the script.

  3. Encrypt the password asymmetrically with the key of a trusted thirdparty. When password gets requested, it must be changed afterwards.

What do you think? Do you see any best practices here?

Reiner Rottmann
  • 633
  • 1
  • 7
  • 19

1 Answers1

3
  1. You should have a secure, encrypted database with all your credentials
  2. A server should be totally inaccessible from the outside by the virtue of firewalls during deployment
  3. It's fine to have a script generate a random pass and email it to you
  4. It's also fine to change that password after the server has been provisioned, BEFORE you've allowed access to the public
  5. Emailing yourself the password is okay, as long as it's using your internal mail server and is not routed via the public over SMTP (SMTPS is a different story)

You can substitute email for just about any protocol. You could sftp the password somewhere, create a one time message using the onetimesecret api, upload it to a private gist using https, or anything else you can think of.

I think that about covers it.

Vasili Syrakis
  • 4,558
  • 3
  • 22
  • 30
  • I agree with you on all points except #3 and #5: Even if your internal mail is secure there is always a chance that an employee will read or forward that mail via an insecure channel, and you're increasing the potential exposure if you have a security breach on your mail server. About the only time I would say it's acceptable to email passwords is if the email itself is encrypted (with something like PGP or S/MIME). – voretaq7 May 15 '14 at 18:49
  • Thats why i put #4. If its changed, the intercepted email is useless. – Vasili Syrakis May 15 '14 at 22:42