2017-08-16 13:55 GMT-03:00 Tim Mackinnon <tim@testit.works>: > ./pharo Pharo.image eval "(ByteString allInstances)” > > I think you would ulimtately find those strings unless the Class encrypts > them in some way right? > > So I’m wondering why we don’t have an EncryptedString object for just this > (I’ve seen lots of cryptography libraries etc), but isn’t this quite a > common thing to deal with? And should Pharo provide something that library > writers adopt to encourage better image safety? Or am I wrong in my > analysis?
It is something imporant, and maybe exceeds Pharo itself and needs sound criptography techniques to overcome, like zero knowledge proofs. It is very common to have "config files" sitting in the same directory as the image, with the credentials to access a remote API, a database or both. My solution in the cases where I was worried about a config file leak was to mitigate the risk, by using symmetric encryption algorithms, where the shared secret is split in two different strings and concatenated at runtime. The image, in turn holds the encryption key also split as two literals. This way the encryption key is not "saved" as a whole literal in the image. In your case you might have to break the secret in more than one part, and pass the parts as arguments. You could also pass it encrypted and decrypt it using the above mentioned technique. It's dirty and it helps with the mentioned mitigation, but it's well known that security by obfuscation won't get you far. Regards, Esteban A. Maringolo
