Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Tweeted twitter.com/StackSecurity/status/699531330665783297
3 added 772 characters in body
source | link

I've got a question about the best practice in storing a Keystore file (.jks) in source control. This Keystore is called by a stand-alone Java component that retrieves a private key for the purpose of signing SAML assertions.

For security purposes I would like to refrain from including this Keystore in the same git project as our Java code. This source code is pushed to many different locations for various tools used. (Code review tools, source code scanners) and I don't think anything good can come from having our Keystore file sitting in all these locations.

That leaves me with the question of, where's the best place to include this file in source control? I've done some digging around the internet have yet to find a good answer so here's my thoughts.

Plan A

I plan to place the Keystore file in a private repo that is locked down. This can only be accessed by a very limited audience. The Keystore will be added to the stand-alone component on build as a dependency by the deployment process.

- Pros

  • Keystore would not be distributed with our source code
  • Updates to the Keystore in source control could be locked down and carefully monitored

- Cons

  • Increased complexity for cert management
  • Keystore will get added to the module in the deploy process anyways, so the security benefit is limited

AmPlan B

Instead of keeping a static keystore, each time the build process is initiated a new keystore is built with a pseudo random key. The key is then added as part of the zip in our build process. Certs will then needed to be added to the keystore. Most of the instances of this Java module would have unique certificates, so not keeping the static reference would not introduce a large amount of busy work.

- Pros

  • No static keystore for attackers to take advantage of

  • Each instance of the keystore has it's own password

- Cons

  • Increase complexity of build process

  • If the same cert is used across multiple instances of this module the cert will have to be added to each one.

Which is my better option? Also am I going down the right path with this?

I've got a question about the best practice in storing a Keystore file (.jks) in source control. This Keystore is called by a stand-alone Java component that retrieves a private key for the purpose of signing SAML assertions.

For security purposes I would like to refrain from including this Keystore in the same git project as our Java code. This source code is pushed to many different locations for various tools used. (Code review tools, source code scanners) and I don't think anything good can come from having our Keystore file sitting in all these locations.

That leaves me with the question of, where's the best place to include this file in source control? I've done some digging around the internet have yet to find a good answer so here's my thoughts.

I plan to place the Keystore file in a private repo that is locked down. This can only be accessed by a very limited audience. The Keystore will be added to the stand-alone component on build as a dependency by the deployment process.

- Pros

  • Keystore would not be distributed with our source code
  • Updates to the Keystore in source control could be locked down and carefully monitored

- Cons

  • Increased complexity for cert management
  • Keystore will get added to the module in the deploy process anyways, so the security benefit is limited

Am I going down the right path with this?

I've got a question about the best practice in storing a Keystore file (.jks) in source control. This Keystore is called by a stand-alone Java component that retrieves a private key for the purpose of signing SAML assertions.

For security purposes I would like to refrain from including this Keystore in the same git project as our Java code. This source code is pushed to many different locations for various tools used. (Code review tools, source code scanners) and I don't think anything good can come from having our Keystore file sitting in all these locations.

That leaves me with the question of, where's the best place to include this file in source control? I've done some digging around the internet have yet to find a good answer so here's my thoughts.

Plan A

I plan to place the Keystore file in a private repo that is locked down. This can only be accessed by a very limited audience. The Keystore will be added to the stand-alone component on build as a dependency by the deployment process.

- Pros

  • Keystore would not be distributed with our source code
  • Updates to the Keystore in source control could be locked down and carefully monitored

- Cons

  • Increased complexity for cert management
  • Keystore will get added to the module in the deploy process anyways, so the security benefit is limited

Plan B

Instead of keeping a static keystore, each time the build process is initiated a new keystore is built with a pseudo random key. The key is then added as part of the zip in our build process. Certs will then needed to be added to the keystore. Most of the instances of this Java module would have unique certificates, so not keeping the static reference would not introduce a large amount of busy work.

- Pros

  • No static keystore for attackers to take advantage of

  • Each instance of the keystore has it's own password

- Cons

  • Increase complexity of build process

  • If the same cert is used across multiple instances of this module the cert will have to be added to each one.

Which is my better option? Also am I going down the right path with this?

2 deleted 19 characters in body
source | link

I've got a question about the best practice in storing a keystoreKeystore file (.jks.jks) in source control. This keystoreKeystore is called by a stand-alone javaJava component that retrieves a private key for the purpose of signing SAML assertions.

For security purposes I would like to refrain from including this keystoreKeystore in the same git project as our javaJava code. This source code is pushed to many different locations for various tools used. (Code review tools, source code scanners) and I don't think anything good can come from having our keystoreKeystore file sitting in all these locations.

That leaves me with the question of, where's the best place to include this file in source control? I've done some digging around the internet have yet to find a good answer so here's my thoughts.

I plan to place the keystoreKeystore file in a private repo that is locked down. This can only be accessed by a very limited audience. The keystoreKeystore will be added to the stand-alone component on build as a dependency by the deployment process.

- Pros

  • Keystore would not be distributed with our source code
  • Updates to the keystoreKeystore in source control could be locked down and carefully monitored

- Cons

  • Increased complexity for cert management
  • Keystore will get added to the module in the deploy process anyways, so the security benefit is limited

Am I going down the right path with this?

Thank you in advance!

I've got a question about the best practice in storing a keystore file (.jks) in source control. This keystore is called by a stand-alone java component that retrieves a private key for the purpose of signing SAML assertions.

For security purposes I would like to refrain from including this keystore in the same git project as our java code. This source code is pushed to many different locations for various tools used. (Code review tools, source code scanners) and I don't think anything good can come from having our keystore file sitting in all these locations.

That leaves me with the question of, where's the best place to include this file in source control? I've done some digging around the internet have yet to find a good answer so here's my thoughts.

I plan to place the keystore file in a private repo that is locked down. This can only be accessed by a very limited audience. The keystore will be added to the stand-alone component on build as a dependency by the deployment process.

- Pros

  • Keystore would not be distributed with our source code
  • Updates to the keystore in source control could be locked down and carefully monitored

- Cons

  • Increased complexity for cert management
  • Keystore will get added to the module in the deploy process anyways, so the security benefit is limited

Am I going down the right path with this?

Thank you in advance!

I've got a question about the best practice in storing a Keystore file (.jks) in source control. This Keystore is called by a stand-alone Java component that retrieves a private key for the purpose of signing SAML assertions.

For security purposes I would like to refrain from including this Keystore in the same git project as our Java code. This source code is pushed to many different locations for various tools used. (Code review tools, source code scanners) and I don't think anything good can come from having our Keystore file sitting in all these locations.

That leaves me with the question of, where's the best place to include this file in source control? I've done some digging around the internet have yet to find a good answer so here's my thoughts.

I plan to place the Keystore file in a private repo that is locked down. This can only be accessed by a very limited audience. The Keystore will be added to the stand-alone component on build as a dependency by the deployment process.

- Pros

  • Keystore would not be distributed with our source code
  • Updates to the Keystore in source control could be locked down and carefully monitored

- Cons

  • Increased complexity for cert management
  • Keystore will get added to the module in the deploy process anyways, so the security benefit is limited

Am I going down the right path with this?

1
source | link

Where should a keystore (.jks) be stored in a repository

I've got a question about the best practice in storing a keystore file (.jks) in source control. This keystore is called by a stand-alone java component that retrieves a private key for the purpose of signing SAML assertions.

For security purposes I would like to refrain from including this keystore in the same git project as our java code. This source code is pushed to many different locations for various tools used. (Code review tools, source code scanners) and I don't think anything good can come from having our keystore file sitting in all these locations.

That leaves me with the question of, where's the best place to include this file in source control? I've done some digging around the internet have yet to find a good answer so here's my thoughts.

I plan to place the keystore file in a private repo that is locked down. This can only be accessed by a very limited audience. The keystore will be added to the stand-alone component on build as a dependency by the deployment process.

- Pros

  • Keystore would not be distributed with our source code
  • Updates to the keystore in source control could be locked down and carefully monitored

- Cons

  • Increased complexity for cert management
  • Keystore will get added to the module in the deploy process anyways, so the security benefit is limited

Am I going down the right path with this?

Thank you in advance!