Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encryption for Sensitive Data #21

Open
ghost opened this issue Aug 29, 2016 · 11 comments

Comments

Projects
None yet
5 participants
@ghost
Copy link

commented Aug 29, 2016

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

This comment has been minimized.

Copy link

commented Aug 30, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Oct 21, 2016

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

@eduardoboucas

This comment has been minimized.

Copy link
Owner

commented Oct 21, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Oct 22, 2016

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

This comment has been minimized.

Copy link
Owner

commented Oct 22, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Nov 6, 2016

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.

@eduardoboucas

This comment has been minimized.

Copy link
Owner

commented Mar 2, 2017

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

@zburgermeiszter

This comment has been minimized.

Copy link
Contributor

commented Mar 3, 2017

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

This comment has been minimized.

Copy link

commented Jan 3, 2018

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. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.