VaultForm (Private Form Tool)

Site Development Tool Suggestions
1

Hi all,

I’ve created a private form tool called VaultForm to solve a personal business pain point of needing to securely send private structured data from one party to another (e.g. I need to get bank info from a contractor to pay them but they don’t have secure messaging). There isn’t anything like this that I could find so I expanded it and made it entirely browser-side encrypted so other people that had the same needs could use this.

I’d like to see if it could be included as a recommendation. My concern is too many people are sharing data in unsecured formats in a pinch, so this might be the tool that helps them. My best guess is that this fits under the encryption tools category but i think it’s a different use case than other products listed there.

I built out a full security walkthrough on the security page that’s (hopefully) straightforward enough for technical and non-technical folks to follow.

Submission guidelines

  • Secure: Tools should follow security best-practices wherever applicable.
    - We use the user’s browser cryptography library to derive keys from their password and OpenPGP.js to generate and secure keys, and to encrypt / decrypt message payloads.
  • Source Availability: Open source projects are generally preferred over equivalent proprietary alternatives.
    - All encryption is client side inspectable, and OpenPGP.js is open source. Our server is currently close sourced.
  • Cross-Platform: We typically prefer recommendations to be cross-platform, to avoid vendor lock-in.
    - This is a web-only application
  • Active Development: The tools that we recommend should be actively developed, unmaintained projects will be removed in most cases.
    - In active development
  • Usability: Tools should be accessible to most computer users, an overly technical background should not be required.
    - The UX is built so that non-tech folks are able to use easily
  • Documented: Tools should have clear and extensive documentation for use.
    - It’s fairly simple to use, but i’ve included documentation and security walkthrough

Developer Self-Submissions

  • Must disclose affiliation, i.e. your position within the project being submitted.
    - I made this project
  • Must have a security whitepaper if it is a project that involves handling of sensitive information like a messenger, password manager, encrypted cloud storage, etc.
    - I have an interactive demo to step through the whole process with documentation linked above
    • Third party audit status. We want to know if you have one, or have one planned. If possible please mention who will be conducting the audit.
      - None planned but would like to in the future
  • Must explain what the project brings to the table in regard to privacy.
    • Does it solve any new problem?
      - I’ve been in the position throughout my career needing to send or receive personally identifiable information in a time sensitive manner, and in general don’t have a Signal chat setup with the other person, or they don’t have PGP setup. Many people end up defaulting to unsecured email, or in the case of structured data, using 3rd party unsecured forms. I want the new default for cases like this to be a encrypted one-way forms that can be only read by the recipient. Unfortunately no tool like this exists.
    • Why should anyone use it over the alternatives?
      - It’s a blend of low friction and good security. Alternatives are either completely unsecured and low friction (email, form tools) or high friction and good security (signal, matrix).
  • Must state what the exact threat model is with their project.
    • It should be clear to potential users what the project can provide, and what it cannot.
      - Threat model is for those that need to transmit information but want to prevent snooping by the software provider, or leaking by a compromised database. The zero-knowledge nature of this tool makes it serve that purpose well.
2

“It’s currently closed-source” This is what stops me from Voting. Otherwise you’ve done a great job :clap:

3

Thank you for the kind words Neo!

I wanted to add more context, not to sway you or anyone else that feels that way at all (totally get it, totally cool), just to give my perspective.

My goal is to make it so you didn’t have to trust the server at all, or anyone involved (me). The server is the part that’s close sourced, and I don’t think open sourcing the server meaningfully improves the security posture of the product since the server is ignorant to the important stuff.

All key generation is using your own browser’s crypto library and openpgp.js, which are all open source and have been audited. The front end functions that handle these are also legible and inspectable (along with the security page using the same packages). Network calls initiated from your browser will also show that the data is encrypted and decrypted only on the browser side. Functions are informatively named and not obfuscated for ease of inspection. All functions related to security and privacy are happening there on your browser.

The open nature of security features makes it more than sufficient to deliver on the promise of a privacy product in my opinion, and separately publishing the server repo does not seem to meaningfully add to the security of the product.

There are concerns with publishing the server code, on the other hand. I have no plans to raise money for this product, and want to get to a point financially to pay for an 3rd party audit directly, by offering premium plans down the line. I’m concerned I won’t be able to do this if I have to financially and legally defend the IP of the product (UI, UX, and server code), which is unrelated to the security of the offering itself.

I know for some people having any aspect of software being closed source will be a deal breaker, and I fully respect that. As a technical person, I end up using mostly self hosted alternatives myself. However, the target users of VaultForm are not the me’s of the world, they are those that want something easy to use, be confident their data won’t be abused or leaked by the platform they are using, whose current alternatives are email, sms, and other entirely untrusted methods. I think it’s important to have recommendations for my friends and family that don’t want to self host their own survey platform, or install a encrypted chat app to use once, to securely pass information one-way. Currently this use case is not accounted for on Privacy Guides.

I wanted to just provide my perspective on this decision transparently, since it was something I had been going back and forth on, and where I’m positioned today. Strong opinions loosely held, this may change in the future.

Thanks again for checking it out!

7 Likes
4

Thank you so much for the explanation :smiling_face:. You now have my vote !

2 Likes
5

Thank you Neo! :slight_smile:

1 Like
6

Is there a vote threshold to get reviewed for approval? I’m curious about the process and not sure if I’m missing something. Thanks!

1 Like
7

Neat! Have to 1st disclose I’m working on a open source survey service currently so I might be a bit bias.

I have a few questions around the encryption / security standards used.

Appears your using pbkdf2 as your KDF, what’s a bit of a dated KDF. Also don’t see the point in randomly generating the server & client key iterations, it adds no security benefit.

OpenPGP’s ECC seems like a better more modern choice over RSA what’s good!

Another issue, it appears survey questions & title aren’t encrypted. So the server would know the general data the user is encrypting, meaning the server could target specific surveys or correlate data about users (e.g. user Mike from X is filling out a survey about workplace sexual harassment, I know accounts for filling out a survey aren’t required, but if you do have a account, the “_vaultform_session” cookie is still sent to the server, what identities you via your email).

Something what doesn’t seem to be mentioned anywhere, are unique public/private keys created per survey or user?

Now my biggest concern with this project aside from not being open source, is it appears to not have any measures to prevent MITM attacks. What stops your “zero trust service”, from providing public keys it knows the private key for instead of the public key created by the poll owner.

2 Likes
8

Hi Ward!

I appreciate the thoughtful comments, definitely glad to see more people trying to solve this problem! No worries about bias, the more people working on solving this and pushing for better solutions the better. Anything to get the standard behavior for more people to be not requesting and sending sensitive data over email & text!

To respond to your points:

  1. Re: pdkdf2 - I wanted to reduce the number of external packages needed to support the functions, so using every browser’s native crypto library and PBKDF2 is fully supported and available out of the box. OpenPGP.js is the only external library used at this time. I’m evaluating Argon2 libraries as well against the tradeoff of adding another external dependency.

  2. Re: randomly generating server & client key iterations not having security benefit - This is largely to support the iteration values as user variables that I can increase over time and for the marginal benefit of making it slightly harder to optimize password attacks. I do agree the random salts are doing the heavy lifting here.

  3. Re: survey titles & questions not being encrypted - These data points are public, since you could create a survey and send that to anybody. Since it’s public data, it would also need to be decrypted server side before display, or client side with a decryption key provided, either way there’s no point for the use cases the tool serves. I do agree with your point about the vaultform_session cookie, I will remove that from all form pages so that it’s clear there’s no way to establish an association from responses.

  4. Re: Keys - These are created with the user account, so all responses to a user are encrypted and decrypted with the same set of keys. The security page on step 4 talks about the public key generated at the user’s account level being used to encrypt response data. That said, one of the improvements I’m looking into is getting keys down to the survey level. Happy to hear if you have more thoughts on this!

  5. Re: MITM - I talk about the source code bit in my response above and totally understand that tradeoff makes it a deterrent for some folks. That said, I think the MITM concern is a concern for all hosted services, open source or not. I definitely don’t describe this tool as “zero trust” as you mention, only that it “zero access” and “zero knowledge” with regard to response data, which I think is an important distinction. I want to be clear in only talking about what the service does do and I don’t claim anything it doesn’t. In the same way you could ask “what’s stopping Proton Mail from encrypting your mail with their own keys after you login”, and the answer is nothing at all. The nature of using any hosted services does require some trust. I could add a signature to the survey itself to indicate the key pair match as a prerequisite to render the form, but the question would still be what’s preventing me from swapping out the signature, and the answer would again be nothing at all. I do think there is a place for hosted services with those tradeoffs in mind, after all I am a happy user of Proton Mail and it is a recommendation on Privacy Guides.

Thanks again for the thoughtful response and creating a constructive conversation around this! :slight_smile:

2 Likes
9

Thanks for the response.

1. pdkdf2:
I understand the want to reduce dependencies, but I’d be careful around the use of pdkdf2, because its definitely becoming dated, and from a security stand point having 2 dependencies (openpgp & some sort of argon package) wouldn’t introduce to much more risk depending on your build system / deployment.

2. survey titles & questions not being encrypted:
It is very possible someone might create a survey with the intent to not make it publicly accessible.

This could be solved simply by locally encrypting the survey title and questions & storing the key in the URI fragment of the URL, that way only users with access to the whole URL could decrypt the survey

4. keys - These are created with the user account
Seems like having keypairs per account and not per survey, especially if the keypair is armored from their password isn’t the best. In the case of someone’s password being compromised they wouldn’t be able to change their password without invalidating past surveys.

5. MITM
To start with I’d argue the Proton Mail example isn’t the best, their mail encryption (for proton to other) is like that due to the limitations of SMTP. Proton Mail’s goal is to reduce the attack surface by storing the emails with zero access. But in the case of Proton Mail to Proton Mail emails, they are sent fully end-to-end encrypted with measures to limit MITM attacks by keeping a signed copy of trusted public keys for users who have communicated with each other (e.g. only on the 1st email to another proton mail user, could the public key be intercepted.)

With VaultForm you could store a hash of the public key in the URL, that way VaultForm would have to both control the public key storage (as you do already) but also anywhere the user decides to share the URL too.

Obviously with any web app their is some level of trust with the site owner, but having measures what can be validated by anyone is a step in the right direction.

Personally for open source software I build, I deploy the frontend via Vercel from the public repo. That way no one can interfere (aside Vercel) without it being obvious.

New concern of mine
The use of a CDN (jsdelivr) for providing any packages, especially something like OpenPGP.js I’d personally try to avoid.

2 Likes
10

Hi, how’s the project going? I was browsing through and looking for a solution to replace Google Forms with a FOSS E2EE solution.

11

Hello, where can I find information about who created it, what it has updated, and about recent news?