title: What's the point of the Wildfly vault (JCEKS) when securing the https keystore?
body: <p>I feel like I'm completely missing the point of the new JCEKS keystore format in Wildfly. Maybe you can set me straight. </p>
  
  <p>The way that we have Wildfly configured (and much of the internet instructs us to, <a href="https://stackoverflow.com/questions/32191742/how-do-i-encrypt-the-bindcredential-password-in-wildfly/32220906#32220906">for example</a>):</p>
  
  <ul>
  <li>We put the standard keystore entries in a standard Java Key Store ("keystore.jks") file with a password ("jks_pw")</li>
  <li>We then create a JCEKS keystore ("keystore.jceks") with a password, salt, and round-count ("jceks_s_n").</li>
  <li>We then put "pks_pw" into "keystore.jceks"</li>
  <li>We then add the JCEKS password/etc ("jceks_s_n") into our jboss config (standalone.xml) as plain text, defining a  entry</li>
  <li>We then add a reference to the vault-stored JKS password to our jboss https connector (standalone.xml), as "password="${VAULT::jks::jks::1}".</li>
  </ul>
  
  <p>What the heck did all of that accomplish???</p>
  
  <p>If we just used a JKS file and a password embedded in standalone.xml, the system is susceptible to:</p>
  
  <ul>
  <li>An attacker getting a copy of standalone.xml and the JKS file, in which case all secrets are known.</li>
  <li>An attacker getting a copy of the JKS file, in which case an attacker can use brute-force or lookup table attacks.</li>
  </ul>
  
  <p>If we use a JCEKS container in the way described, the system is susceptible to:</p>
  
  <ul>
  <li>(SAME) An attacker getting a copy of standalone.xml, the JKS/JCEKS files, in which case all secrets are known.</li>
  <li>(SAME) An attacker getting a copy of the JKS file, in which case an attacker can use brute-force or lookup table attacks.</li>
  </ul>
  
  <p>This would sort of make sense if we put the actual certs inside of the JCEKS file, in which case brute-force and lookup table attacks would be harder in the second case of attack, but so far I haven't found a way to use a JCEKS-formatted keystore directly with an https connector.</p>
  
  <p>Really, the only reason I care too much about this is that we apparently have a security requirement to use the "vault", but it seems pointless.</p>
  
  <p>UPDATE: It is worth noting that by using the vault you're using a "masked" password to the vault in your jboss config file, but I can't figure out what this means. Apparently your masked-password + salt + rounds can unlock the JCEKS keystore (<a href="https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/Mask_the_Keystore_Password_and_Initialize_the_Password_Vault..html" rel="nofollow noreferrer">source</a>), so I'm not sure what exactly masking accomplishes. It just seems like a third level of redirection. I've got to be missing something...</p>