Encryption for Sensitive Data

[ghost]

Hey guys —

I think a great feature would be to have encryption of sensitive data. Since part of the joy of staticman is the ability to run a website through github, it could be very useful to be able to encrypt certain data coming in from html forms (eg. email addresses of commenters) before they hit github.

Would it be possible to specify a public encryption key in the config file and have staticman encrypt incoming data using the specified key before merging it on github? That way the data is simultaneously both accessible and safe.

Just an idea!! Awesome little service, Staticman.

-A

[robsonsobral]

I think it's a good idea. However this opens a door: the use of Staticman for contact forms.

Go ahead with that, but keep this on mind.

[zburgermeiszter]

You can take it even further.
Maybe someone wants to encrypt the vendor/repo/branch details, that could be an encrypted field in the form instead of url argument, and the request would be sent to a general endpoint and send the repo name data ad a field that is optionally encrypted.
For this please also refer to the Travis method as mentioned in #20.

[zburgermeiszter]

If this helps: You can use node-rsa module which is pure JS, no dependency on OpenSSL.

[eduardoboucas]

Thanks, @zburgermeiszter, really appreciate it. I'm actually using that on the new version of the API, which I'm hoping to release in the next couple of weeks.

[zburgermeiszter]

How do you going to encrypt the config values?
Encrypt an object and save the string somewhere, OR encrypt single values and use transformations (or sign somehow) to know which to decrypt?

The first is more compact, and guarantee that the config key names are also encrypted in order to stop any snooping.

On the other hand it is much easier to update single encrypted values give the freedom not to remember what key-value pairs has been encrypted as the key is plaintext.

[eduardoboucas]

Encrypted config values will still go in the main config file just like regular values. Keys will be in plain text, so that the config file is still readable, but the documentation will flag that certain properties need to be encrypted.

[zburgermeiszter]

Not sure if you have met with this issue, but it seems the RSA public key encryptionis not suitable for encrypting long values.

Sometimes I get the following error:
Error: error:04065084:rsa routines:RSA_EAY_PRIVATE_DECRYPT:data too large for modulus
And this comment also confirms that.

I'll need to work a bit more on this idea.

[kishaningithub]

Travis has this feature though
http://stackoverflow.com/questions/9338428/using-secret-api-keys-on-travis-ci
https://docs.travis-ci.com/user/environment-variables/#Encrypted-Variables

[eduardoboucas]

@zburgermeiszter This should be relatively easy to implement now that we have encryption for config files. What do you think?

[zburgermeiszter]

Few questions.

Now it is 2 separate feature. One for encrypting form fields, and another for encrypting repo/path.

How I would do this, is to reuse your config file transformation code, but instead of decrypting encrypted config values, it could check in the site config what submitted field to encrypt, and save to the comment yml.
But, more importantly how would the site owner be able to decrypt those values?
We can not really provide a public decrypt endpoint because then there's no benefit of using encrypted fields when everyone can decrypt them.
I need come clarification on this.

But encrypting or at least base64 encoding the repo/path would make sense, because then we would use a general process endpoint, and receive the git provider name (gitlab support) and the repo/branch names as a B64 encoded or RSA encrypted JSON wich is very flexible.
Or alternatively we can simply move these details to a simple form field as an unencrypted json, but you have mentioned some reason in the past why you would prefer to keep these details in the path, which I can not remember now.

Thanks

[JokerQyou]

The idea of encrypting repository and branch name is great. Say if one got a private repository for his website, it might be inappropriate to expose repo name and branch directly in the HTML form. Instead, we could do something like this:

Let's say Alice got a repository named awesome-website, and the website builds on branch main.

• Alice first encrypt repository info using /v2/encrypt API, turn awesome-website/main into encrypted value 5ECREtI029;
• Then point the HTML form action to /v3/entry, add a field named options[repository.secret] with a value of 5ECREtI029;
• When staticman receives a request, for each option field of which its name ends with .secret, the server decrypts the value. This way the repository information is now available for validation and entry processing.

Glad to hear any suggestions on the above workflow. :)