You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
According to the official Java Cryptography Architecture, you should not use String for storing the Vault token but instead use char[] to safely and securely handle security-sensitive information.
This feature makes String objects unsuitable for storing security-sensitive information such as user passwords. You should always collect and store security sensitive information in a char array instead.
Describe the solution you'd like
Internal handling of the token as a char[] and passing directly to the HTTP header X-Vault-Token. I know the restriction is that the HTTP header code only accepts a String, for this case it is acceptable to use new String(...) and pass in the char[] token because the String will be short-lived and not passed to other areas of the application.
Describe alternatives you've considered
I know a lot of legacy code may utilize the String as a token, therefore I suggest utilizing CharSequence to maximize legacy code compatibility as people slowly transition to using char[]. I propose providing 2 methods on the VaultConfig class to maximize compatibility:
publicvoidsetToken(CharSequencetoken) {
// store token
}
publicvoidsetToken(char[] token) {
// store token
}
Additional context
I've made some of those changes on my forked branch already, you can view those changes here.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
According to the official Java Cryptography Architecture, you should not use
String
for storing the Vault token but instead usechar[]
to safely and securely handle security-sensitive information.Describe the solution you'd like
Internal handling of the token as a
char[]
and passing directly to the HTTP headerX-Vault-Token
. I know the restriction is that the HTTP header code only accepts aString
, for this case it is acceptable to usenew String(...)
and pass in thechar[]
token because theString
will be short-lived and not passed to other areas of the application.Describe alternatives you've considered
I know a lot of legacy code may utilize the
String
as a token, therefore I suggest utilizingCharSequence
to maximize legacy code compatibility as people slowly transition to usingchar[]
. I propose providing 2 methods on theVaultConfig
class to maximize compatibility:Additional context
I've made some of those changes on my forked branch already, you can view those changes here.
The text was updated successfully, but these errors were encountered: