Securely storing secrets

[Daniel Beck]

(This is discussing a class of potential security issues -- if you want to mention how it's a problem in a specific plugin, please report to our secure tracker instead. Thanks!)

Hi everyone,

I've just posted another security advisory:
https://jenkins.io/security/advisory/2017-08-08/

This advisory is about a plugin not storing secrets as such on disk. The same issue in a different plugin was already fixed yesterday.

This email is intended as a reminder: Please make sure to store secrets in your plugin either…

1. As Secret: http://javadoc.jenkins.io/hudson/util/Secret.html
2. Integrating with Credentials Plugin: https://github.com/jenkinsci/credentials-plugin/tree/master/docs

Either works and achieves the following goals:

1. Other users with local file system access to JENKINS_HOME (questionable, but probably common) can't access the secrets/ directory, and therefore not decrypt secrets.
2. Backups that exclude the secrets/ directory don't compromise secrets even if the backups are made accessible to unauthorized people. This also applies to job config history plugin, SCM sync configuration plugin, and similar.
3. No secrets get round-tripped in plain text and show up in the DOM etc. exposing them for example to evil browser plugins.

Going from String to Secret first (to quickly fix the exposure), integrating with credentials later (usually better, but more work), is also a viable approach. There's no reason to not at least go with the former.

If you maintain a plugin and it currently stores secrets in plain text, and you need help fixing it, file an issue in the SECURITY project in Jira, and we (the security team) will try to help.

Daniel

[Jesse Glick]

On Tue, Aug 8, 2017 at 10:44 AM, Daniel Beck <m...@beckweb.net> wrote:
> Backups that exclude the secrets/ directory don't compromise secrets even if the backups are made accessible to unauthorized people.

To clarify, it is just `secrets/master.key` which should be excluded
from backups. The rest of the `secrets/` directory is (at least in
theory) unreadable without `master.key`, and in fact *should* be
backed up if you plan to be able to do anything after restore from
backup without recreating every secret in the system. It is convenient
to exclude `master.key` since, once created on initial startup, it
never changes and so can be kept on a sticky note in your bank vault.
Cf.

https://go.cloudbees.com/docs/cloudbees-documentation/cje-user-guide/index.html#backup-sect-configure

[Jesse Glick]

On Tue, Aug 8, 2017 at 10:44 AM, Daniel Beck <m...@beckweb.net> wrote:

> Backups that exclude the secrets/ directory don't compromise secrets even if the backups are made accessible to unauthorized people.

[Daniel Beck]

> On 8. Aug 2017, at 16:55, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> The rest of the `secrets/` directory is (at least in theory)

initialAdminPassword remains from the 2.0 install wizard if you don't customize the admin user.