Re: [Pharo-users] Encoding Login information in your image (safely)

[Pierce Ng]

On Wed, Aug 16, 2017 at 02:24:15PM -0300, Esteban A. Maringolo wrote:
> 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

Take a look at SpsSplitPasswordStore, which is a simple secret splitter.

  http://ss3.gemtalksystems.com/ss/SpsSplitPasswordStore.html/
  http://samadhiweb.com/blog/2013.08.11.splitpasswordstore.html

Can be adapted to encrypt/decrypt the secret, with the cipher key also split,
perhaps with one part stored in the image and another part fetched online from
somewhere.

I haven't touched the code in a while, but the Pharo 5 image that runs my blog
is using this for the RFBServer passwords.

Pierce

Re: [Pharo-users] Encoding Login information in your image (safely)

[Dimitris Chloupis]

I am clueless when it comes to encryption and safety , so as you would
expect I will offer my opinion on this.

I do not think that encryption from the side of Pharo would be a good idea
because having the image you have access to everything . Including any kind
of context even its not stored in a variable.

I think the safest way is not to use Pharo and do this in C and put this in
a DLL which Pharo cannot access other than calling its functions. This way
you can be certain that the user has no way to hack the data unless of
course its disassemble the DLL and inspect the memory but that would be
much harder than do it in Pharo. Of course an average Pharo user/coder does
not have this technical knowledge , sometime we cannot even figure out UFFI
problems but a determined hacker wont have an issue disassembling the DLL
(reading the machine code).

Of course you could use one of the countless security libraries for C from
Pharo using UFFI.

But yeah personally I would not allow Pharo to have any kind of access to
that information just call DLL function that will reply only if a yes/no
about the success of the login attempt. The rest I would leave it to my DLL
and the C security library.

But then I am not a believer of safety of any kind. Life is very unsafe but
of course its wise to try to make it safer :)

On Wed, Aug 16, 2017 at 7:55 PM Tim Mackinnon  wrote:

> Hi - I’m struggling to find something that I saw that discussed this issue
> kind of.
>
> In my image (its actually a headless one - but this could apply to a fat
> image too) - I build an application that needs access to a  service (in
> this case an S3 bucket).
>
> The AWS library I’m using (but others are similar) has an AWSLogin class
> singleton where I can specify a username and password. So in a playground I
> can do that and test it all works etc.
>
> However, for deployment its never a good idea to encode this info into
> your code (particularly if you use Iceberg and GitHub) - SO, I am using
> secret variable support in GitLab - which I’ve seen many projects do in
> other languages. This way, I type in those details into an encrypted place
> in the CI and it then exposes them as temporary variables when I build my
> system (so far so good).
>
> Now in my build - I run a little script like this and pass on those
> variables (neatly, Gitlab doesn’t show their values in its logs):
>
> ./pharo Pharo.image --no-default-preferences --save --quit st config.st \
> *"{**‘**$USER'. ‘$PWD'}"*
>
>
> In config.st I then extract these command line parameters (the ST handler
> nicely exposes the extra parameter array so I didn’t have to do anything
> custom)
>
> "Expect image to be called with params as a last arg array"
> config := Array readFrom: Smalltalk arguments last.
> *user* := config at: 1.
> *pwd* := config at: 2.
>
> DBConfig default
>accessKey: user;
>pKey: pwd;
>yourself.
>
> So it all looks pretty good so far - however it occurs to me that if you get 
> hold of a .image and were to browse all of the Strings - e.g.
>
> ./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?
>
>
> Tim
>
>
>

Re: [Pharo-users] Encoding Login information in your image (safely)

[Tim Mackinnon]

Todd, i think you are right, I can't get around it - I need to pass something 
from my live environment (where it's kept encrypted) into my image.

I can however potentially simplify the setup by passing a single key that I can 
use to unlock a PasswordVault in my image and it can have multiple values which 
I can then use for my different api keys.

When creating my image, I can encode those values in a less hostile environment 
and pass them through like I do now, where they get stored in the PasswordVault.

This seems pretty simple now I talk it through.

Thanks to everyone for additional ideas - it's useful to know it's not a simple 
X thing that I've missed.

Tim

Sent from my iPhone

> On 16 Aug 2017, at 19:41, Todd Blanchard  wrote:
> 
> I do a lot of deployments on AWS elastic beanstalks.
> 
> I put the credentials into environment variables on the beanstalk.
> 
> When running locally, the credentials are in the environment on my machine.
> 
>> On Aug 16, 2017, at 9:55 AM, Tim Mackinnon  wrote:
>> 
>> Hi - I’m struggling to find something that I saw that discussed this issue 
>> kind of.
>> 
>> In my image (its actually a headless one - but this could apply to a fat 
>> image too) - I build an application that needs access to a  service (in this 
>> case an S3 bucket).
>> 
>> The AWS library I’m using (but others are similar) has an AWSLogin class 
>> singleton where I can specify a username and password. So in a playground I 
>> can do that and test it all works etc.
>> 
>> However, for deployment its never a good idea to encode this info into your 
>> code (particularly if you use Iceberg and GitHub) - SO, I am using secret 
>> variable support in GitLab - which I’ve seen many projects do in other 
>> languages. This way, I type in those details into an encrypted place in the 
>> CI and it then exposes them as temporary variables when I build my system 
>> (so far so good).
>> 
>> Now in my build - I run a little script like this and pass on those 
>> variables (neatly, Gitlab doesn’t show their values in its logs):
>> 
>> ./pharo Pharo.image --no-default-preferences --save --quit st config.st \
>> "{‘$USER'. ‘$PWD'}"
>> 
>> In config.st I then extract these command line parameters (the ST handler 
>> nicely exposes the extra parameter array so I didn’t have to do anything 
>> custom)
>> 
>> "Expect image to be called with params as a last arg array"
>> config := Array readFrom: Smalltalk arguments last.
>> user := config at: 1.
>> pwd := config at: 2.
>> 
>> DBConfig default
>>accessKey: user;
>>pKey: pwd;
>>yourself.
>> So it all looks pretty good so far - however it occurs to me that if you get 
>> hold of a .image and were to browse all of the Strings - e.g.
>> ./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?
>> 
>> Tim
>> 
> 

Re: [Pharo-users] Encoding Login information in your image (safely)

[Todd Blanchard]

I do a lot of deployments on AWS elastic beanstalks.

I put the credentials into environment variables on the beanstalk.

When running locally, the credentials are in the environment on my machine.

> On Aug 16, 2017, at 9:55 AM, Tim Mackinnon  wrote:
> 
> Hi - I’m struggling to find something that I saw that discussed this issue 
> kind of.
> 
> In my image (its actually a headless one - but this could apply to a fat 
> image too) - I build an application that needs access to a  service (in this 
> case an S3 bucket).
> 
> The AWS library I’m using (but others are similar) has an AWSLogin class 
> singleton where I can specify a username and password. So in a playground I 
> can do that and test it all works etc.
> 
> However, for deployment its never a good idea to encode this info into your 
> code (particularly if you use Iceberg and GitHub) - SO, I am using secret 
> variable support in GitLab - which I’ve seen many projects do in other 
> languages. This way, I type in those details into an encrypted place in the 
> CI and it then exposes them as temporary variables when I build my system (so 
> far so good).
> 
> Now in my build - I run a little script like this and pass on those variables 
> (neatly, Gitlab doesn’t show their values in its logs):
> 
> ./pharo Pharo.image --no-default-preferences --save --quit st config.st 
>  \
> "{‘$USER'. ‘$PWD'}"
> 
> In config.st  I then extract these command line parameters 
> (the ST handler nicely exposes the extra parameter array so I didn’t have to 
> do anything custom)
> 
> "Expect image to be called with params as a last arg array"
> config := Array readFrom: Smalltalk arguments last.
> user := config at: 1.
> pwd := config at: 2.
> 
> DBConfig default
>accessKey: user;
>pKey: pwd;
>yourself.
> So it all looks pretty good so far - however it occurs to me that if you get 
> hold of a .image and were to browse all of the Strings - e.g.
> ./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?
> 
> Tim
> 

Re: [Pharo-users] Encoding Login information in your image (safely)

[Richard Sargent]

Apologies for top quoting; there isn't any single place which seemed
appropriate.

A colleague of mine who worked for a Swiss bank (they take security
seriously) addressed this by NOT keeping the credentials in the image.

1. Set up a distinct user intended solely for running the application.
2. Set up a credentials file which can only be read by that user.
3. When the application runs, it can read the credentials from the file,
open whatever connection it needs and then release the credentials from
image memory.

I think this concept may be similar to how SSH keys (private keys) are
managed.



Tim Mackinnon wrote
> Hi - I’m struggling to find something that I saw that discussed this issue
> kind of.
> 
> In my image (its actually a headless one - but this could apply to a fat
> image too) - I build an application that needs access to a  service (in
> this case an S3 bucket).
> 
> The AWS library I’m using (but others are similar) has an AWSLogin class
> singleton where I can specify a username and password. So in a playground
> I can do that and test it all works etc.
> 
> However, for deployment its never a good idea to encode this info into
> your code (particularly if you use Iceberg and GitHub) - SO, I am using
> secret variable support in GitLab - which I’ve seen many projects do in
> other languages. This way, I type in those details into an encrypted place
> in the CI and it then exposes them as temporary variables when I build my
> system (so far so good).
> 
> Now in my build - I run a little script like this and pass on those
> variables (neatly, Gitlab doesn’t show their values in its logs):
> 
> ./pharo Pharo.image --no-default-preferences --save --quit st config.st \
> "{‘$USER'. ‘$PWD'}"
> 
> In config.st I then extract these command line parameters (the ST handler
> nicely exposes the extra parameter array so I didn’t have to do anything
> custom)
> 
> "Expect image to be called with params as a last arg array"
> config := Array readFrom: Smalltalk arguments last.
> user := config at: 1.
> pwd := config at: 2.
> 
> DBConfig default
>accessKey: user;
>pKey: pwd;
>yourself.
> So it all looks pretty good so far - however it occurs to me that if you
> get hold of a .image and were to browse all of the Strings - e.g.
> ./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?
> 
> Tim





--
View this message in context: 
http://forum.world.st/Encoding-Login-information-in-your-image-safely-tp4961690p4961706.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Encoding Login information in your image (safely)

[Esteban A. Maringolo]

2017-08-16 13:55 GMT-03:00 Tim Mackinnon :
> ./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