Hi,

Assuming you mean the classical pattern of giving char[] and the zeroing it out? That doesn’t apply here.

The SDK must retain knowledge of the password, since if there is a connection break it must be able to do ActivateSession again once reconnected, thus it needs the password at that time again. In theory after the UaClient.disconnect there would be no more need to know, unless doing another .connect on the same object. This is one of the general reasons why systems increasingly try to move away from user passwords. User-certificates would avoid the need to have the password in memory, however please note below.

Note that the same also applies to the private keys related to the application (and user) certificates. They are also in memory. We must be able to pass those to BouncyCastle lib to do crypto operations as byte[]. Here as well a reconnect will need to be able to make a new SecureChannel. Also the SecureChannel is renewed in addition even if there are no connection breaks.

The SDK cannot protect against an environment where process memory itself is not secure. If an attacker is able to make a memory dump, they are likely to have enough privileges to modify the application and SDK code running on the JVM itself. Thus, if you yourself make a memory dump, it should be treated with care. Maybe you can post-process it to remove sensitive information if you must give it to someone.

P.S.
In theory it might be possible to some day support hardware-backed private keys. It might also be possible to have some callback for the user password to be given as char[] each time it is needed, though an implementation of that would need to have non-memory-based storage, and it would still leave a timing window when the password is in memory. At least currently none of these are on our roadmap.