[to be squashed]address comments on credential store for password guide

_posts/2023-11-09-credential-store-for-passwords.adoc

@@ -10,14 +10,16 @@ author: prarthonapaul
 :toc: macro
 :toc-title:
 
+WildFly allows the use of credential stores to keep alias for sensitive information, such as, passwords for external services. Credential stores can be used to store different credentials under aliases and use credential-reference to specify them in server configuration. As a result, the credential is no longer visible in clear text. 
+
+toc::[]
+
 == Prerequisite
 To follow along with this guide you will need:
 
 * about 10 minutes
 * WildFly with credential-store support  
 
-WildFly allows the use of credential stores to keep alias for sensitive information, such as, passwords for external services. Credential stores can be used to store different credentials under aliases and use credential-reference to specify them in server configuration. As a result, the credential is no longer visible in clear text. 
-
 == About Credential Reference
 There are multiple uses for credential stores, but this blog post will dive deeper into using credential-stores to avoid specifying passwords in clear text. Passwords are used for various resources when configuring the WildFly server, such as a `key-store` or a `key-manager`. While it is quick and easy to specify the passwords in clear text, it is not very secure. 
 
@@ -32,14 +34,14 @@ Once the server is running, open another terminal and connect to the cli to conf
 ```
 Now we can create a keystore using a plaintext password: 
 ```
-/subsystem=elytron/key-store=serverKS:add(path=server.keystore, relative-to=jboss.server.config.dir, type=JKS, credential-reference={clear-text=secret})
+/subsystem=elytron/key-store=serverKS:add(path=server.keystore, relative-to=jboss.server.config.dir, type=PKCS12, credential-reference={clear-text=secret})
 ```
 
 When configuring a resource using plaintext password, it is stores in the standalone.xml file as seen below: 
 ```
     <key-store name="serverKS">
         <credential-reference clear-text="secret"/>
-        <implementation type="JKS"/>
+        <implementation type="PKCS12"/>
         <file path="server.keystore" relative-to="jboss.server.config.dir"/>
     </key-store>
 ```
@@ -55,24 +57,37 @@ As you can see, the password can easily be obtained from the standalone.xml file
         "required" => false,
         "provider-name" => undefined,
         "providers" => undefined,
-        "type" => "JKS"
+        "type" => "PKCS12"
     }
 }
 ```
 However, this can be changed using a credential-store and alias to point to the password instead. 
 
 == Create a Credential Store
 A credential store can hold multiple passwords at once, with each password uniquely identified by an alias. When we want to use a password for a resource, we can specify which credential-store it is in and which alias it is under. Let's first create a credential store: 
+
 ```
 /subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)
 ```
+
 If you navigate to WILDFLY_HOME/standalone/configuration, you will see a new file has been created there named mycredstore.cs. This file is used to store all the credentials in a credential-store. If you try to open it using Vim or another file viewer, you will see that the file is not human readable. As a result, the passwords are secured. It is possible to programmatically read the passwords, which is what WildFly does when dereferencing the credential reference to access a resource. 
 
-== Add a Password to the Credential-Store
-Now in order to use the credential-store for our keystore, we need to add the keystore password to it: 
+== Add an Entry to the Credential-Store
+In order to use the credential-store for our keystore, we need to add the keystore password to it: 
 ```
 /subsystem=elytron/credential-store=myCredStore:add-alias(alias=kspass, secret-value=secret)
 ```
+Here, `alias` is the unique identifier that is used to refer to this password entry inside the credential store. The `secret-value` refers to the actual value of the password.
+
+=== Disable History for the Management Console
+As you may have noticed, above that we specified the password to be added to the credential store in clear-text. So while it would no longer appear on the standalone.xml file, if someone went through the management CLI history, they can easily find the password. In order to avoid this, we can disable the history using the command below: 
+```
+[standalone@localhost:9999 /] history --disable
+```
+Once you have added your passwords to the credential store, you can enable history again using the command below: 
+```
+[standalone@localhost:9999 /] history --enable
+```
 
 == Update the Keystore Credentials
 Now, we can edit our keystore to use the credential store instead of the clear-text password: 
@@ -94,7 +109,7 @@ Now if we use the read-resource function, we can no longer see the password:
         "required" => false,
         "provider-name" => undefined,
         "providers" => undefined,
-        "type" => "JKS"
+        "type" => "PKCS12"
     },
     "response-headers" => {"process-state" => "reload-required"}
 }
@@ -134,23 +149,23 @@ As you can see from the output, the credential-store has been updated to add a n
         "required" => false,
         "provider-name" => undefined,
         "providers" => undefined,
-        "type" => "JKS"
+        "type" => "PKCS12"
     }
 }
 ```
-Notice how even though we specified the clear-text password when updating the credentials, it does not show up here. Instead, we can see the name of the credential-store and the alias listen under credential-reference. 
+Notice how even though we specified the clear-text password when updating the credentials, it does not show up here. Instead, we can see the name of the credential-store and the alias listed under credential-reference. 
 
 == Remove Unused Credentials
 If you are no longer using an and would like to remove it from the credential store, then you can do that using the following command: 
 ```
 /subsystem=elytron/credential-store=myCredStore:remove-alias(alias=myalias)
 ```
-However, when deleting a alias, you must be careful, as if the alias is in use, it may still be removed successfully, leaving the resource's credential-reference pointing to a non-existent alias. 
+However, when deleting an alias, you must be careful. If the alias you are trying to delete is currently in use, it may still be removed successfully, leaving the resource's credential-reference pointing to a non-existent alias. 
 
 == Summary
 This blog post introduces us to credential stores and introduces us to one of the use cases for them. There are other use cases for credential-stores when securing resources in the WildFly server. Future guides will cover other use cases. 
 
 == Resources
 * To learn more about credential stores, please refer to the https://docs.wildfly.org/30/WildFly_Elytron_Security.html#CredentialStore[documentation]
 * To learn more about automatic credential-store updates, visit https://wildfly-security.github.io/wildfly-elytron/blog/automatic-credential-store-updates/[this blog post]
-* You can also use the read-resource-description function in command line to learn more about the credential-reference resource. 
+* You can also use the `read-resource-description` function in command line to learn more about the credential-reference resource.