Securely storing secrets

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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


--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/A8F2B272-99ED-4816-BC27-591AED6F4E1B%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Securely storing secrets

Jesse Glick-4
On Tue, Aug 8, 2017 at 10:44 AM, Daniel Beck <[hidden email]> 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

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1OH82xiOb2YvckB1TPoqeqnGW9ujA%3Db4dW3n%2B4Mb7%2BOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Securely storing secrets

Jesse Glick-4
In reply to this post by Daniel Beck
On Tue, Aug 8, 2017 at 10:44 AM, Daniel Beck <[hidden email]> 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

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr03Sj0fDPeMZfdMyZrespks_5hf4j5sEdvURaCA%3Dk-AFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Securely storing secrets

Daniel Beck
In reply to this post by Jesse Glick-4

> On 8. Aug 2017, at 16:55, Jesse Glick <[hidden email]> 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.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/DE4F1ACD-D16F-42DE-BC9A-8A4752BE889F%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Loading...