It is best practice to encrypt these details in memory, but you need to undertake some sort of threat modelling process and see if it justifies the overhead.
It would seem your primary risk is users reading memory using appropriate tools - this requires malicious intent and a fairly sophisticated user. Is this a likely threat scenario? What they can access if they do compromise the credentials? Is it just data on the local machine?
Memory dumps are another potential issue, if an error occurs, or a malicious user forces a fault and memory is dumped to logs, the data may be retrievable from these logs.
Swap files and hibernation files may also contain this data as memory is swapped out or if the device hibernates while the credentials are in memory.
There are multiple tools available to you to protect against these cases, types such as SecureString in .Net framework, there are also data protection APIs provided by the MS operating systems. Secure String as one user has already replied are immutable and encrypted and they are also stored in multiple locations in memory. I would use constructs such as this provided by the frameworks and the OS and avoid rolling any of your own code to secure the data in RAM.