If the stack is opened in the IDE then it can easily be accessed. In a standalone, it's safe. A standalone only has the text editing functions that the scripts allow, so if you block the copy function then the text can't be extracted. I allow pasting but not copying. In addition, just in case, I also empty the field on openField if the user clicks in it which means they can't even select existing text. They have to type it anew.
The user is limited to the login card until the credentials are verified, and after that the text is removed from the fields. There is probably one case in which a hacker could access the credentials, and that is if they have installed a key logger or can watch the data stream before it is sent to the server (which would be just before transmission, since the credentials are encrypted with SSL when actually sent.) In that case the method is as vulnerable as any other login method on any other app or web site.
One other trick I like about this method is that you can briefly display the character typed if you do not lock the screen during text entry. This is a side-effect of the time it takes to implement an imageSource. The effect is similar to what mobile apps do during password entry. If you do lock the screen before setting the imageSource then there is no brief display, so you can control whether or not you allow the user to verify their typing as they go.
I've used the imageSource method on both desktop and mobile apps and it works well on both. On mobile I do not use native fields because I have more control over text entry in LC fields and for single-line text a LC field works fine.
I guess it depends on your definition of "left behind." On desktop apps I sometimes don't store the password but on mobile it's truly a pain to type on an on-screen keyboard repeatedly. My client specifically requested that the credentials be automatically entered on launch if there has been a valid login in the past. So I get the contents of the verified fields the first time, encrypt them, and store them in the app's sandbox where they are protected from user access on both Android and iOS. When the user launches the app, the stored data is unencrypted and placed into the fields (using imageSource on the password field.) This doesn't ensure a valid login though; the entries are sent to the server normally just as though the user had typed them. It just saves the user from the tedium of the virtual keyboard.That is why Richmond, and then I, went the "No password left behind" way.
This proved so convenient that we also use the same method on dekstop apps now. If the data is encrypted, it's probably reasonably safe as long as your app is saved as password protected.