Add a security.txt well-known file about reach4help HOT 8 CLOSED

With that in mind, my suggestion for the page is

# If you would like to report a security issue, please use the contact information below.
Contact: mailto:[email protected]

# Our security policy
Policy: https://github.com/reach4help/reach4help/blob/master/SECURITY.md

# You can contribute to our project, it’s open-source
Contribute: https://github.com/reach4help/info

Let me know what you think @s0

from reach4help.

that looks good to me, feel free to open a PR to add it, the folder to add it to would be: https://github.com/reach4help/reach4help/tree/master/site/static

from reach4help.

It would be nice to create a GPG key associated with that email address, so people can send us encrypted emails, and we can sign the emails sent from that address (if required, we can extend this to other email alias). We can then put the fingerprint on the security.txt page and upload the public key to a keyserver or host it on the website.

Some issues to consider:

• Depending on the email provider, we need to use 3rd-party apps or browser extensions to be able to send/receive encrypted emails. For example, Gmail does not support GPG, but we can use FlowCrypt or Mailvelope, or use Thunderbird together with enigmail.

from reach4help.

I'm actually more inclined to not suggest the use of GPG for incoming emails, and rely on decent SMTP TLS infra for emails, and our own auth configuration in gsuite.

from reach4help.

The advantage of using GPG is that E2E encryption can be used in emails sent to us, and also allows us to sign emails (e.g. to avoid tampering) sent to others. While TLS encrypts the data in transit, Google (and its affiliates) still have access to the content at rest.
GPG can be useful for situations where someone wants to send us an email with sensitive information (e.g. they found sensitive and/or personal data exposed on the app).

However, since GMAIL/GSuite does not have "native" integration of GPG keys, we need to do some workarounds as I explained in my previous comment. With that in mind, we can ignore GPG for the MVP, and add it later if we think it is necessary.

from reach4help.

Right, my thinking is that it's more of a trade-off of ease-of-use vs E2E security.

I think E2E encryption has it's uses, particularly in private communication, activism, journalism, etc... and I'm usually a big advocate of it, used to take part in key-signing parties etc...! However I also am very aware of its limitations.

Encouraging / requiring that researchers report to us using GPG may impact how fast we're able to respond to security disclosures, particularly if any of the on-call team are not as familiar with GPG. It also means that we need to start doing GPG key management on-top of everything else.

As far as encrypting-at-rest on google's servers, I don't think we have a threat model that gives us cause to worry about that. Even if people need to send us sensitive information, it's not any more sensitive than the information that google already deals with and has both legal and technical safeguards in place to protect.

As far as authenticity goes, i feel i'd much rather rely on DKIM and google's auth provisioning mechanisms than try to start also managing GPG keys around the security team.

With all that being said, even if we did list a GPG key, I have a feeling that the majority of the emails we get will not be signed or encrypted. If my experience working with a security research team and being involved in the security disclosure process for a number of vulnerabilities has taught me anything, it's that reporters find any additional work needed to report a vulnerability very frustrating, and often ignore requests such as using GPG (given it's not an easy to use piece of software), or just end up not reporting at all!

So all-in-all, i think it would be a lot of additional work for very little gain.

Those are my thoughts, though I'm happy to defer to @mdeous to make a call on this.

from reach4help.

In other words, it's more important that we respond to an email as rapidly as possible than ensure that Google can't see the contents of an email =)

from reach4help.

Encouraging / requiring that researchers report to us using GPG may impact how fast we're able to respond to security disclosures, particularly if any of the on-call team are not as familiar with GPG. It also means that we need to start doing GPG key management on-top of everything else.

I agree that it can be a bit cumbersome to set up a GPG key, and because of that I agree that we can skip the GPG issue for the MVP, as I said before. However after being configured, it's a pretty transparent process for who is responsible for that email alias.

We will not encourage or require researchers to use it, it's just an extra option that they have if they really want to encrypt their emails content.

As far as encrypting-at-rest on google's servers, I don't think we have a threat model that gives us cause to worry about that. Even if people need to send us sensitive information, it's not any more sensitive than the information that google already deals with and has both legal and technical safeguards in place to protect.

I kinda disagree with this one, because it's more a privacy issue that actually to secure the information, because that is ensured during transport with TLS. Of course Google is "secure" but their fame regarding users' privacy is not the best 😀

As far as authenticity goes, i feel i'd much rather rely on DKIM and google's auth provisioning mechanisms than try to start also managing GPG keys around the security team.

You are mixing up different things. One thing is DKIM (which obviously must be set and properly configured, together with SPF and DMARC), which ensures that there's no spoofing regarding the email server, i.e. that the email really came from the email server specified in the headers (gmail in this case). It's good to prevent spam, phishing, etc.
GPG signing is all about the message content validation, i.e. it ensures that the content that is on the received email was written by the person that actually sent it.

With all that being said, even if we did list a GPG key, I have a feeling that the majority of the emails we get will not be signed or encrypted.

I totally agree. However researchers that have GPG configured on their email will probably use it. Also there are some email providers that use GPG by default, like Protonmail.

So all-in-all, i think it would be a lot of additional work for very little gain.

I agree that for this stage it's not a mandatory thing. I mentioned it because I think it can be important in the future, and also because it's suggested by security.txt. And ofc because I personally use it 😛 .

from reach4help.