# Disclosure of S3 secret access key
**URL:** https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221
**Category:** Feature
**Created:** [10.Май.2018 23:47:06 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221 "2018-05-10T23:47:06Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Asher\_Densmore-Lynn](https://meta.discourse.org/u/Asher_Densmore-Lynn)
#### Post date: [10.Май.2018 23:47:06 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/1 "2018-05-10T23:47:06Z")
I was working on a Discourse forum – v2.0.0.beta9 – recently, when I spotted the Files tab of the administrative settings. I was surprised to see the S3 secret key displayed to the user, and I was horrified to observe that my changes to it were echoed, in full, in the dashboard logs.
This means that an attacker who manages to simply observe the Files tab has the ability to seize _and delete_ Discourse backups during a rampage.
Please consider not displaying the secret key to even administrative users, and simply noting who changed the key and when in the audit trail.
Thanks.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [10.Май.2018 23:54:21 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/2 "2018-05-10T23:54:21Z")
This is a bit of a catch-22, how is the admin entering the setting supposed to not see the setting they are entering?
Better advice is to simply limit who has admin access, and limit who has direct SSH access to the server.
---
### Author:  [@Asher\_Densmore-Lynn](https://meta.discourse.org/u/Asher_Densmore-Lynn)
#### Post date: [11.Май.2018 00:08:37 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/3 "2018-05-11T00:08:37Z")
They can see it when they set it, but when the UI is loaded, that field should be blank. If somebody shoulder-surfs me they should see the userID and the blank password field, just like the password-change dialogue on every user account page on every website I’ve encountered since the mid-2000s.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [11.Май.2018 00:18:07 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/4 "2018-05-11T00:18:07Z")
I see, so you’re advocating for having the field hidden behind an extra click?
---
### Author:  [@Asher\_Densmore-Lynn](https://meta.discourse.org/u/Asher_Densmore-Lynn)
#### Post date: [11.Май.2018 00:25:11 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/5 "2018-05-11T00:25:11Z")
Well, my preference would be to standardize on the usual behavior – it should not appear even to the administrator; there should be a field where the administrator sets it, and it should load /blank/ instead of filled. Honestly, the only time I ever see click-to-reveal is when you’re dealing with something designed to store _sets_ of credentials, not a single one, but click-to-reveal would resolve that half of it, yes.
Either way, though, the log entries that show setting changes that echo the password back in plaintext are… not a common behavior.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [11.Май.2018 00:25:54 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/6 "2018-05-11T00:25:54Z")
You can set them in the app.yml file and have them not show up in settings. [Docker deployment with custom site\_settings.yml - #4 by sam](https://meta.discourse.org/t/docker-deployment-with-custom-site-settings-yml/31914/4) provides hints
---
### Author:  [@Asher\_Densmore-Lynn](https://meta.discourse.org/u/Asher_Densmore-Lynn)
#### Post date: [11.Май.2018 00:33:01 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/7 "2018-05-11T00:33:01Z")
Well, yeah, and I can use an EC2 instance-role too and honestly I probably will be switching to that.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [11.Май.2018 00:50:48 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/8 "2018-05-11T00:50:48Z")
Do you have any thoughts on how we could improve here @mpalmer? It is a Discourse core value™ to be safe by default, so it is worth thinking about any small things we can improve here as we go.
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [11.Май.2018 01:10:11 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/9 "2018-05-11T01:10:11Z")
There’s two separate issues here, to my mind:
1. **Logging changes to sensitive data** : I think that definitely needs to be fixed. We scrub passwords and API keys from logs, the same thing should definitely apply to S3 secret keys, IMO.
2. **Shoulder-surfing creds** : Leaving the box blank, even though there’s a value set, seems like a UX nightmare – I predict “I entered the S3 key and _now it’s gone!_” support requests if we did that. It is handy to be able to check on an entered value to make sure it’s right – I’ve noticed a steady increase in the number of password entry boxes that have “click to show” ability. That seems like a reasonable middle ground to me – hide it behind dots or something by default, with a “click to show” option.
---
### Author:  [@Asher\_Densmore-Lynn](https://meta.discourse.org/u/Asher_Densmore-Lynn)
#### Post date: [11.Май.2018 01:19:36 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/10 "2018-05-11T01:19:36Z")
That’d settle it for me, yes.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [11.Май.2018 01:26:37 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/11 "2018-05-11T01:26:37Z")
I think we should do part 1 in the 2.0 release, @techapj can you assist? It seems relatively straightforward, if we are doing it elsewhere? Let me know if it is not.
---
### Author:  [@techAPJ](https://meta.discourse.org/u/techAPJ)
#### Post date: [15.Май.2018 01:25:07 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/12 "2018-05-15T01:25:07Z")
While we are at it, should we scrub all these “secret” settings from staff logs?
- google\_oauth2\_client\_secret
- twitter\_consumer\_secret
- instagram\_consumer\_secret
- facebook\_app\_secret
- github\_client\_secret
- s3\_secret\_access\_key
The previous and new value will be replaced with `[FILTERED]`, just like what we do in `/logs`. Example:
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [15.Май.2018 01:35:52 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/13 "2018-05-15T01:35:52Z")
Yes probably, I think the same logic would apply.
---
### Author:  [@techAPJ](https://meta.discourse.org/u/techAPJ)
#### Post date: [15.Май.2018 03:55:26 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/14 "2018-05-15T03:55:26Z")
Part 1 done in:
[https://github.com/discourse/discourse/commit/abcb6af8f953101a1f20b5e231f52cc81867bd38](https://github.com/discourse/discourse/commit/abcb6af8f953101a1f20b5e231f52cc81867bd38)
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [15.Май.2018 03:56:00 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/15 "2018-05-15T03:56:00Z")
I guess the logic should be, screen any setting from logs that has the string “secret” in it? Or `_secret` if you want to be careful.
---
### Author:  [@techAPJ](https://meta.discourse.org/u/techAPJ)
#### Post date: [15.Май.2018 03:59:05 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/16 "2018-05-15T03:59:05Z")
> [@codinghorror](#):
>
> screen any setting from logs that has the string “secret” in it? Or `_secret`
Got it. Will amend the logic to scrub any setting that has `_secret` in the name.
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [15.Май.2018 04:09:07 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/17 "2018-05-15T04:09:07Z")
Since I’m sure more sensitive settings will appear in the future, and plugins may add some also, would it be particularly tricky to add the ability to mark “sensitive” site settings as such in `site_settings.yml`?
---
### Author:  [@techAPJ](https://meta.discourse.org/u/techAPJ)
#### Post date: [15.Май.2018 04:11:29 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/18 "2018-05-15T04:11:29Z")
Done in:
[https://github.com/discourse/discourse/commit/8d6a9eb51114b35cab006ed284240e8c84dd3276](https://github.com/discourse/discourse/commit/8d6a9eb51114b35cab006ed284240e8c84dd3276)
As per the current logic, these 8 settings will be scrubbed:
- google\_oauth2\_client\_secret
- twitter\_consumer\_secret
- instagram\_consumer\_secret
- facebook\_app\_secret
- github\_client\_secret
- s3\_secret\_access\_key
- push\_api\_secret\_key
- sso\_secret
> [@mpalmer](#):
>
> add the ability to mark “sensitive” site settings as such in `site_settings.yml`
Added on my list.
---
### Author:  [@Asher\_Densmore-Lynn](https://meta.discourse.org/u/Asher_Densmore-Lynn)
#### Post date: [15.Май.2018 04:22:18 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/19 "2018-05-15T04:22:18Z")
Wow, thanks a lot. Just in time for me to… switch to instance-role credentials. 😃
But seriously, thanks for getting it done!
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [15.Май.2018 04:56:55 UTC](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221/20 "2018-05-15T04:56:55Z")
I presume you’re familiar with the security considerations around instance role creds and SSRF vulnerabilities? It’s quite a pity AWS doesn’t protect the metadata store with a magic header like GCP does.
[Следующая страница](https://meta.discourse.org/t/disclosure-of-s3-secret-access-key/87221.md?page=2)