If you use OpenSSL (or any other crypto library) they provide secure memory allocation that can be used to store sensitive data such as keys, initialization vectors, etc. You can even encrypt the data stored there. Once freed, that allocation wipes the memory used. Of course there would still be the case of the String/ByteArray in the image or in method contexts when passed as arguments, for that there isn't much to do except if you pass that "allocation object" as parameter and convert it right to a String at the moment of using it, or better, map it and pass it to another FFI call. Also there is the risk of stack traces leaking sensitive information. It would be convenient to have a "SecureString" that is never dumped (and also has its secure allocation outside of the heap). Depending on where you run your software, having a password in the heap that is read from a file with the right permissions is all you need. I never needed to do any of the above, but I know some people that do, especially for desktop apps. YMMV. Best regards! Esteban A. Maringolo On Tue, Sep 20, 2022 at 11:59 AM <sean@clipperadams.com> wrote:
I feel compelled to revive this old (almost 10 years!) thread because Iâm faced with a similar problem and certain points seem unresolved.
Assuming that one needs the actual password in the image (in my case to authenticate via IMAP), Norbertâs suggestion to have a helper app that runs with elevated privileges makes sense, but Iâm wondering about a few other comments:
Sven mentioned that itâs common to have sensitive info âlying aroundâ on the filesystem, with .ssh being an example. However, my (non-expert) understanding is that the best practice to add a passphrase to oneâs private key protects against just such situations as we consider here, no?
There seems to be a hard distinction drawn between memory and disk storage. However, this being Smalltalk, this seems only to be the case if the image is guaranteed never to be saved, otherwise its memory, including any plaintext sensitive information, would end up on disk.
As I was thinking through my use case, I was considering, for example, storing the password in a non-string collection e.g. ByteArray, so that I could use the password and zero it out in memory right afterward.