I decided that we are already quite off-topic. So let’s discuss notions of security in this thread.
In many applications, security is not black and white, but can indeed have different qualities that may even allow for a quantification.
A car is more secure if it has airbags. Without airbags, a car is not unsecure in all cases.
An encrypted PGP communication is more secure if a longer key size has been employed. This is why we updated key lengths from time to time. Interestingly, security may change in time if the assumptions do not hold anymore. Fukoshima is not secure any longer and also plants identical in construction may be less secure nowadays.
Let’s get back to the question of images and file names. One could define a level of security that depends on the number of educated guesses or the probability to find out a secret (e.g. a file name). In this sense, a longer secret (file name) is certainly more secure. I agree that there are cases where it is impossible to guess the secret, e.g. one time pad.
Or… you can just use global incrementing counter and short natural numbers. Sorry, if that sounds stupid, i’m not familiar with reasons why guid-s were selected for attachments (i know all advantages and disadvandages, but don’t know what is more important for discourse).
I believe that attachments don’t have any validation on them when you request them, so with an incremental id, you could easily guess and retrieve attachments from topics and pms that you otherwise can’t access.
“security by obscurity” is not safe approach. For example, if someone index email content of notifications about new messages… people can suddenly find you secrets in image search.
Let’s consider this scenario: The whole must-register forum with 1k people uses mailing list mode and somebody creates a post with few photos.
I do not see another mean to protect the photos in the forum while still making them accessible from within mail viewers than using random filenames. I’m not even sure if security of obscurity hits the nail. The adversary knows how the algorithm works. She or he just don’t know the secret filename.
If forum users share the secret filename, or their user password is somehow equivalent. By assumption, they don’t. Of course, Google can index the mails, but they have a promise to keep it private. Forums that use the Google login must trust Google anyway.
In this case you could prepare different content for email and for thread. For example, email can have embedded images (not public accessible link).
The only way to keep public link in secret - never show it anywhere. Seriously.
Forums that use the Google login must trust Google anyway.
If you trust google auth, that does not mean you should trust it everywhere. I’d like to say that security does not work such way. You must have proofs that all involved 3rd-party services and users do not compromise security. That’s impossible via primitive shared secret without server side check.
People discussed the idea to send out only PGP encrypted mails. If this idea would be implemented, I agree that it would be nice to also increase the security for images and embed them. However, at the moment I appreciate that mails are small in size because I do not have GMail with unlimited storage.
It’s impossible to “increase” security. It can exist or not exist. No half state. If you decide to provide security, then public-accessible links are not good choice. If you don’t care - you can use plain numbers and have short links. There are cases, when guid-s are useful - for parallel clustered uploads, but that’s not related to security anyhow.
Why do you think that an unguessable download link is less secure than requiring password authentication for the download? Both models hinge on the assumption that some string is not guessed.
No. Link with public access will be shared in unpredictable ways. You can not provide security at this step. So, you can not rely on assumption that your “secret link” will be secret forever, this can go out of your control.
You cannot protect against that: The file itself could be shared just as unpredictably as the link. You have to assume that users won’t share the file with the attacker; why would you assume that these links are more likely to be shared?
Intended share !== unintended leak. If you use public links, you can guarantee nothing at all. And you will create wrong illusion of safety.
The most obvious sample - when you distribute notifications, you can not be sure, that nobody scan content and do something with links if those are public.
This is a nonsensical argument; do a forgot password reset via email on any website and you will get what is, in essence, a clickable unguessable random GUID. If you forward that email with the clickable GUID or it is intercepted by an attacker… you are gonna have a bad time.
The only thing that can protect you is two factor auth.
I do not agree. Proper OTP token implementation includes client IP check. If you reset password or request auth link, you should click it from the same device (and in limited time). Even if link leaks, it will not be useable, because another person/bot will have invalid IP address.
That’s intended to solve another kind of issues, not unexpected data leak mentioned before.
There is no big problem here, because operations like login/reset via email are executed in very limited time frame (~ 30 sec) and should not be affected by ip/device change. Well, may be 1 of 1000 will re-request token - that’s acceptable price for security.
Anyway, as you noted, situations are different and should be analyzed independently.I did not invented anything new for files, just repeaded well known basics of security design principles.
There is a lot of complexity here that is missing from the discussion. Let me try to unwrap some of this. There are a bunch of types of uploads Discoruse can get:
Totally public uploads, (category is not read restricted, or a PM)
Semi private uploads, (category is read restricted)
Private uploads (category is a PM)
To add a bit more complexity here
Topic can transfer between states, a PM can become a public topic, a public topic can becomes a semi private topic and so on.
Uploads can be images or files
Topics can get deleted
We always prefer to use a CDN for images
And layer on some more complexity uploads can be images or attachments (uploads that are not images)
We implement 2 security mechanisms at Discourse.
Increased barrier security (GUID for images)
ACL based security, you must be both logged in and have access to a topic to download attachments. (Eg: when you upload a text file or zip file or whatever)
ACL based security kills the option of using a CDN, you simply can not have the image live on the CDN in any “simple” way without jumping through insurmountable hoops to server an asset from a CDN and check with Discourse for security.
Increased barrier security ™ is not 100% safe and can in certain cases leak out if you forward an email and then your friend forwards the emails again and so on.
So, to answer the original question here.
No, GUIDs for filenames are not 100% secure under all conditions. Nothing is really.
They are absolutely unguessable, however people can leak them out if they want to.
But what about people taking “screenshots” of a page at Discourse and sharing them? How do we stop that problem?
I do feel that since
We want to keep the CDN working
You can not guess a GUID
This is secure enough for image uploads, though if you were running some sort of MEGA private site I would be totally open for a site setting that passes all images via the ACL path as well and disallows CDNs.
I do not want to introduce a “simpler” mechanism (eg: id only) for public topics cause of the portability problem. It makes the code that has to change a topic to a PM or and code that changes security need to be much smarter and rebake posts and so on.
To conclude I just don’t see what we have now as having any major issues, but open to improvements for MEGA private installs that care not for CDNs.
of a page at Discourse and sharing them? How do we stop that problem?