Don't use Strings when handling Secrets

[Mark Cuijk, van]

The Secret class seems to be introduced to promote safe handling of sensitive material, like passwords. Internally, it stores a secret as byte[] and it has an erase() method to prevent sensitive material to be stored in memory for a long time.

However, it does have a constructor accepting a String and a getValue() returning a String. Additionally, it does not have a constructor accepting a byte[], so when using the class, I’m forced to put credentials in a String (or use the constructor that generates a random password and overwrite the values of the byte[] with the sensitive material).

At a minimum, I’d like to see:

1. A Secret(byte[] value) constructor
2. The remainder of the library not have the sensitive material converted to String, e.g. ResourceOwnerPasswordCredentialsGrant.toParameters().

Preferably, to promote safe handling of sensitive material by users of the library:

1. Deprecate the Secret(String value) constructor and String getValue() method

‌

[Yavor Vasilev]

Thanks Mark for these suggestions.

Making use of byte[] within Secret will solve the issue internally with the Secret class, but I’m not sure how we can have no Strings appearing elsewhere, e.g. in ResourceOwnerPasswordCredentialsGrant.toParameters() you mention. Have you got any ideas?