Protecting the password is important but the problem doesn't end there. Say my LabVIEW built application queries the OS to decide if the current user has some privilege at launch time. How should my code remember that fact? Do I put it in a LabVIEW global variable boolean called "IsAdmin"? Guess where my weak link is. Forget about attacking the password. If I can find the right byte, I can turn any user into an admin. Or even before that, what if I can attack the code the decodes the answer from the OS. Any application that runs on the users machine and internally makes decisions about allowable operations is susceptible to in memory attacks (through debuggers or code insertion).
There are a few LabVIEW-specific things you can do to reduce this exposure.
Subroutine priority - Subroutines are less exposed through VI server.
Inline VIs - Inlining of security critical VIs means there is no longer a single bottleneck that the user can attack to gain access to multiple pieces of functionality. Each piece must be attacked separately.
Request Deallocation node - This node causes all temporary allocations for a VI to be disposed at the end of a subVI's execution. This does not necessarily overwrite the memory but could help. (I'm not sure what happens if you try to use this in a VI that is set to inline.)
If we apply these to the issue of remembered state, then you might create inline VIs that know how to get and set into some obscured form of remembered state. Of course that just moves your weak link to be the algorithm used to obscure your state.