2

Edited to clarify: *The bucket is used by EC2 instances that process its data and display parts of it to the user. The EC2-S3 interaction is invisible to the user. *

Can I assume that a public S3 bucket will not be discovered if it has a very long and complicated URL?

For example s3://5eb63bbbe01eeed093cb22bb8f5acdc8/

One could argue that this is not "security by obscurity", but "security by secrecy".

David_Springfield
  • 184
  • 10
  • How are you defining the difference? – schroeder Aug 01 '19 at 16:58
  • We've had a few questions like this over the years: https://security.stackexchange.com/questions/36870/is-including-a-secret-guid-in-an-url-security-through-obscurity – schroeder Aug 01 '19 at 17:00
  • There's not really enough detail to answer this. If you're hosting assets in the bucket and using them in a webpage then it certainly isn't a secret - it will show up in the browser logs of everyone who connects to your website. So I think you need to clarify: how exactly are you using the bucket? – Conor Mancone Aug 01 '19 at 17:28
  • I'd pick a better seed than "hello world", personally... – gowenfawr Aug 01 '19 at 23:39
  • @gowenfawr 71d3e8b42792b5e476804f4f7fbddc58 – David_Springfield Aug 02 '19 at 14:53

2 Answers2

4

Bottom line, the answer is No.

If your S3 bucket is public, and you make it a website, the bucket name will appear in certificate logs which are fully public. There are tools that sniff certificate logs just to find such S3 buckets.

Also if you make it a website -- it'll appear in the links you're presumably sharing out.

The way to secure an S3 bucket is to make it private, and grant access to the specific IAM roles that need access. Do not rely on long complicated names to protect it alone.

That being said -- if you truly don't want anyone to find the stuff in your bucket, I'd definitely give it a long complicated name and make it private. It at least adds some layer of protection, for the times where maybe some script somewhere turns it public (AWS is complicated!)

Also, the recommended way to expose an S3 bucket website is usually CloudFront, where your bucket can remain fully private, yet still expose its contents to the internet. This way, folks can't perform bucket operations like list buckets without being granted the specific permissions.

keithRozario
  • 3,571
  • 2
  • 12
  • 24
  • see my edit. But -- you say "Do not rely on long complicated names to protect it alone" - why not? isn't your API (key+secret) just that? – David_Springfield Aug 02 '19 at 15:07
  • hey @David_Springfield, Yes indeed an API Key is just a long complicated string of characters, but there's a difference between an API Key and a Bucket Name. A Bucket name by definition has to be publicly known, while an API Key is meant to be kept a secret. If attackers wanted to access my private bucket, they'd need to know the name of the bucket **and** guess my API Key (not easy!). If they wanted access to my public bucket, they'd only need to know my bucket name (which they can glean from different sources) – keithRozario Aug 03 '19 at 01:50
  • Agree and this is one of the reasons I love this website. Different perspectives on the same issue. – David_Springfield Aug 03 '19 at 16:34
1

First, standard disclaimer: Security is not an all or nothing proposition. Security procedures for an anonymous favorite-cat-voting website will not be as stringent as the security procedures for the nuclear football. You need to decide on a security level that property balances cost vs usability for your organization.

That being said, I agree with keithRozario's answer, and will give you a couple more reasons on top of his why I personally wouldn't rely on just the bucket name.

The public is not the only "group" to worry about

Many studies show that roughly half of all data breaches start internally. Even if the "public" never guesses your bucket name, that doesn't help if the group that is responsible for half of all data breaches (aka your employees) does know your bucket name. Like anything else, if it contains production data, it should only be accessible to employees who need access to production data. If you have a "secret" bucket name but embed it in your source code where everyone can see it, then it isn't really a secret, and you may in fact have problems in the future.

Access keys can be rotated, bucket names can't

In a comment you asked why a long bucket name was different from API access credentials. There is a very simple reason why they are in fact very different. If the employee in charge of your production systems leaves on bad terms, you can invalidate their access credentials, create new ones, and update your systems. However, it's not always as easy to change the name of your bucket.

It's like the difference between a building that has magnetic card entry vs a single master key. With magnetic card keys, if someone leaves, you just revoke their access. When everyone has a single master key then you have no choice but to change the locks and replace everyone's key when one person leaves, which in reality means that the locks never change. Relying on the bucket name for security is equivalent to giving out the master key to everyone who works for you. No thank you.

Community
  • 1
Conor Mancone
  • 29,899
  • 13
  • 91
  • 96