and gain access to the bucket. I guess most will use some kind of organizing structuring names for buckets, meaning that if you know one you can guess/know all (like test0, test1, test2 etc. and oh look what http://link.tardigradeshare.io/s/1N2...49/test1/ exposes!)
On the other hand, if the bucket name was encrypted, somebody who knows the sintel link and even manages to find out there must be a fireplace bucket, he would not be able to access it easily, because he would not be able to change the URL to the correct encryption value. (Surely someone could try to bruteforce it but that would be possible with clearnames as well)
So the question remains, why bucket names are not encrypted and if that would not add additional security against unwanted exposure of data.
My guess is that this is hard to do due to the desire to have S3 compatibility. I would recommend using more restricted access grants to just prevent people from having access to your other buckets with the same or similar link.
The satellite UI should generate one access grant per file. How did you generate these links? The access grant in it gives me full access to your entire account.
For safety I moved this thread into a private area. I don’t want anyone to gain full access to your account. I would like to delete the links but I don’t have the priviliages for that.
Yes I know that and it is only test data in that account. I guess the Access Grants were created through the satellite UI via ‘Access Grants’ ‘All Buckets’. By the way these are the default setting when you create an Access Grant through web: All buckets, All permissions, Forever. I had already suggested in the past that these default settings are a terrible idea.
I’m still a little lost… did you just use that full access grant to create this URL’s manually? That kind of feels like you went out of your way to expose the whole account. I feel like I’m missing something.
I created the Access Grant with default settings and pasted the Access Grant into the Url together with the bucket name.
Why? This is an account purely made for testing. It is filled with worthless test data. I had even forgotten the encryption phrase, but I have just remembered it again.
Ok, well if you know what you’re doing that’s fine of course, but I don’t really understand your second point in your first post then. This isn’t standard functionality, you went out of your way to manually create a link with full exposure. Had you used the link sharing feature from the satellite interface, you would have gotten a link that only grants read access to the specific object shared. The concern you raise requires this weird way to manually create the link while knowingly using an access grant with full rights to the account.
The interface even calls it sensitive information and you pasted it in a public URL.
You can’t then be surprised that it would expose other buckets as well.
I am not surprised. But how is this not standard functionality? Obviously when I create an Access Grant via the satellite UI, it gets registered in the linkshare application ready to be exposed. There is no information about that btw. The UI absolutely offers these steps to create Access Grants, it is not a hack or something. Even worse, the UI sets the permission to all buckets, all permissions and forever duration.
And by the way if you want to share access to an entire bucket and not just to a single file afaik the link sharing feature does not offer such a way so I have to go that route.
With that it is only a matter of time until such unwanted exposures will happen and the question is, if it is a good idea (maybe it is required as you have suggested in your first post) to expose the bucket structure in such a way?
At the least you are confirming that you want this access grant to have full access. You have the option right there to restrict it to a single bucket. You didn’t and then you shared your full access grant by manually pasting it in a public url.
To me that sounds like:
You chose to create an access grant with all permissions
You chose to then expose that access grant
You somehow blame Storj for this exposure?
To be clear, I’m not talking about the bucket names being visible here. I think that may be necessary, but I’m not entirely sure. I know there is an encrypted version of the paths, so in theory that could be used in the url, but any access grant that provides access to the object it points to would also allow you to decrypt that path anyway. So I’m not sure how useful encrypting the path would be to begin with.
So we can have a discussion about showing bucket names and object paths. But what I don’t get is how you can manually create an access grant with access for all buckets and then say it exposes other buckets… yeah, of course it does, you told it to.
Is it because it’s called an access grant and not a password?
I assume you would never put a password in a url… but an access grant is basically the same thing. It is what grants you access to whatever rights you give it.
I’m still confused… I guess I’ll leave it to others to respond for now. Sorry I couldn’t be more helpful.
And why does such or similar advice exist? Because things happen.
You expect a user to fully know what he is doing and to fully understand the consequences. This is not the case otherwise leaks would not happen. They don’t happen because users want them to happen, they happen because user do something out of their best intention, because they mess up something or whatever.
Looking at the implementation here tells me that unwanted leaks are just a matter of time. Not just because the lack of bucket name encryption. It is also because the interface lacks any information that helps properly maintain the Access Grants. There is no information what buckets are included, no information what permissions are associated with them. Also no information about the duration. And even no option to add such information manually. It completely relies on the ability of the user to self maintain these kind of information and keep it updated. Honestly like I have said it before this feels like the recipe for a disaster.
There is a lot of information in our documentation on Access Grants, how to use them, the relationship between Access Grants and S3 compatible gateway credentials.
In terms of Brightsilence’s comment on microwaving cats, I think he’s describing the species of security vulnerability related to unintentional credential sharing. It is possible on any storage platform to create a leaky bucket - essentially to share an access credential with unintended, overly broad scope.
We do our best to make our S3 compatibility as private and secure as possible. We also do our best to reduce as much of the complexity around access management and encryption to make it easy for developers to leverage those for greater privacy and security within those applications.
I’d encourage you to take a look at the documentation links above. We’d definitely like the feedback on how we can reduce the probability of a security error. If you have feedback on what we can do either in the documentation or the product interface to improve things, our product team is engaged in the forum and actively incorporates feedback into the product process.
As expected, there might be an unintentional leak already. I will not disclose it here in public, but I am asking URGENTLY to be contacted via DM by a Storj member.
As a first step this can help, however it does not completely solve the underlying issue. And I think you even made it worse:
I just happened to be able to test on the test satellite and noticed that for some reason every new user now has a bucket called ‘demo-bucket’. Now that gives every ‘hacker’ a wonderful starting point where to look for potential data leaks.
I did not test this but it seems together with the default settings for creating Access Grants (which gives all permissions for all buckets) the ‘demo-bucket’ is included when a user creates an Access Grant with default permissions and therefore will be exposed automatically.
So whenever I get to see a StorJ DCS linkshare publically shared, I can try out if bucket ‘demo-bucket’ is accessible and what data it contains. I don’t think this is how it should be.
Any bucket can be exposed, if you creates unlimited access grant, independently of how it was created - via UI or CLI.
Do not share unlimited Access grant. Treat the Access grant as a secure password to your data.
If you do not mind to expose all your project - you can share this secure password, otherwise it would not wise.
The best practice will be to use --url option in uplink share with timelimits or share from the Objects browser. In both cases you will have an URL which contains only part of the key. You need a second one to have a more wide access. However, even if you get it, since the --url generates an Access grant with read-only permissions, it would not help much (but you of course can change default permissions with caveats during the sharing).
