From the article: This doesn't seem too common, but it's a good reminder that when you send someone a private message and expect them to keep it secret, you are implicitly trusting not just them...
From the article:
Popular malware/url analysis tools like urlscan.io, Hybrid Analysis and Cloudflare radar url scanner store a large number of links for intelligence gathering and sharing. It is however not so widely known that these services also store a large amount of private and sensitive links, thanks to:
Sensitive links mistakenly submitted by users for scanning unaware that these are public information
Misconfigured scanners and extensions submitting private links scanned from emails as public data
This doesn't seem too common, but it's a good reminder that when you send someone a private message and expect them to keep it secret, you are implicitly trusting not just them but all the software they run. That includes the email program, but also the web browser, any extensions they install, and any security software they install.
(If it really matters, I would recommend Signal as a way of minimizing this concern.)
Random keys in a URL is just "security through obscurity" which is another way of saying "not secure at all." If you want your data to be at least somewhat secure, you need to use a service that...
Random keys in a URL is just "security through obscurity" which is another way of saying "not secure at all."
If you want your data to be at least somewhat secure, you need to use a service that has authentication involved, not a URL that is just inconvenient to type.
I wouldn't frame it like that. Sure, you can say that the security is just that you don't know the right string to put in the URL - but you can also say that about any secret, which is all...
Random keys in a URL is just "security through obscurity" which is another way of saying "not secure at all."
I wouldn't frame it like that. Sure, you can say that the security is just that you don't know the right string to put in the URL - but you can also say that about any secret, which is all authentication. The only reason I can't post on your tildes account is that I don't know your password. The only reason you can't SSH into my computer is that you don't know my private key. A URL can have arbitrary strings in them, which is more than enough entropy.
The real issue with random keys in URLs is that URLs are leaked all over the place! That's why the attack in the article works, because URLs are not treated like confidential information and their contents are sprayed onto various places by the intermediaries (like your browser) in the chain.
Interesting to me that they mentioned onetimesecret links in there. It's not a perfect tool from a security perspective (anyone can access the link), but at least that burns the secret so that if...
Interesting to me that they mentioned onetimesecret links in there. It's not a perfect tool from a security perspective (anyone can access the link), but at least that burns the secret so that if your intended recipient cant access it, you have a clue something went wrong. It beats the heck out of sending secrets through email or chat, and you can selfhost if you don't trust the onetimesecret.com folks.
I made a highly relevant comment on a different thread just last week. Tl;dr: I assert that there's not a clear-cut line between "public" and "private". In the context of this topic, tools like...
I made a highly relevant comment on a different thread just last week. Tl;dr: I assert that there's not a clear-cut line between "public" and "private".
In the context of this topic, tools like these operate on that grey area where there's confusion between systems about how "private" a resource is. The tools which generate these links assume they are private because they are non-enumerable and intended not to be shared; but other tools which handle the links assume they're not because URLs are, in general, not private data.
I would argue the latter perspective is wrong-er (the generality may hold, but obvious exceptions are widespread; URL-embedded credentials, e.g. https://username:GJK4V3BVc9OPL8dc1YNu@example.com, blur the lines further), but it's tough to make a convincing case in either direction. Ultimately, the World Wide Web is, ironically, not well designed for widespread, international use.
From the article:
This doesn't seem too common, but it's a good reminder that when you send someone a private message and expect them to keep it secret, you are implicitly trusting not just them but all the software they run. That includes the email program, but also the web browser, any extensions they install, and any security software they install.
(If it really matters, I would recommend Signal as a way of minimizing this concern.)
Random keys in a URL is just "security through obscurity" which is another way of saying "not secure at all."
If you want your data to be at least somewhat secure, you need to use a service that has authentication involved, not a URL that is just inconvenient to type.
I wouldn't frame it like that. Sure, you can say that the security is just that you don't know the right string to put in the URL - but you can also say that about any secret, which is all authentication. The only reason I can't post on your tildes account is that I don't know your password. The only reason you can't SSH into my computer is that you don't know my private key. A URL can have arbitrary strings in them, which is more than enough entropy.
The real issue with random keys in URLs is that URLs are leaked all over the place! That's why the attack in the article works, because URLs are not treated like confidential information and their contents are sprayed onto various places by the intermediaries (like your browser) in the chain.
Interesting to me that they mentioned onetimesecret links in there. It's not a perfect tool from a security perspective (anyone can access the link), but at least that burns the secret so that if your intended recipient cant access it, you have a clue something went wrong. It beats the heck out of sending secrets through email or chat, and you can selfhost if you don't trust the onetimesecret.com folks.
I made a highly relevant comment on a different thread just last week. Tl;dr: I assert that there's not a clear-cut line between "public" and "private".
In the context of this topic, tools like these operate on that grey area where there's confusion between systems about how "private" a resource is. The tools which generate these links assume they are private because they are non-enumerable and intended not to be shared; but other tools which handle the links assume they're not because URLs are, in general, not private data.
I would argue the latter perspective is wrong-er (the generality may hold, but obvious exceptions are widespread; URL-embedded credentials, e.g.
https://username:GJK4V3BVc9OPL8dc1YNu@example.com, blur the lines further), but it's tough to make a convincing case in either direction. Ultimately, the World Wide Web is, ironically, not well designed for widespread, international use.