Not really sure what you mean by reusing UUIDs but theres nothing bad about using UUIDs in URLs for content you don’t want scrapped by bots. Sites like Google Photos are already are using UUIDs in the URL for the photos, and do not require any authentication to see the image as long as you have the URL. You can try this for yourself and copy the URL of an image and open it in a Private Browsing Window. Every so often someone realizes the actual image URL is public and think they’ve found a serious issue, but the reason why it isn’t is because of the massive key space UUID provides and that it would be infeasible to check every possible URL, even if it’s publicly available.
You point out the “vulnerability” yourself, sometimes (when it’s Google) it works as designed, but a less robust site could have the full access through a UUID for example and then someone shares an image with it, bam they have access to more than they should. The history is littered with bulletproof things like this ending up being used wrongly.
It’s not security through obscurity in this case. The filenames can’t be obtained or guessed through brute force. At least not with current technology or processing power…
Security through obscurity is when you hide implementation details.
Saying that my suggestion is security through obscurity is the same as telling that ASLR is security through obscurity…
It taking a long time doesn’t make it an impossibility. The fact that it has a limit of 122 bits, in and of itself, makes the possibility of a bruteforce a mathematical guarantee.
By this logic, all crypto is bruteforcable, on a long enough timeline.
A 122 bit random number is 5316911983139663491615228241121378303 possible values. Even if it were possible to check 1 trillion records per second, it would take 168598173000000000 years to check all the UUIDs and get the info on all the users. Even if every human on earth signed up for the app (~8 billion people), and you wanted to just find any one valid UUID, the odds of a generating a UUID and that being valid in their DB is basically 0. You can do the math your self following the Birthday Paradox to determine how many times you would need to guess UUIDs before the probability that any one UUID is valid against a population of the whole world is greater than 50%.
You should read into the NSA’s Translator. Granted, it’s relatively outdated with shifting text algorithms, but for a very long time (about half a century), it was able to bruteforce any key, regardless of length, in under an hour.
I’m not familiar with NSA’s Translator, so any info would be appreciated.
I saw your other comment about DES, and it should be noted that DES was with a key length of 56 bits, and that was enforced precisely because the NSA could brute force it. It wasn’t even a secret they could brute force 56 bit encryption, and written into law. Back then, if you wanted to use more than 56 bit encryption in the United States, you had to provide a key escrow system to allow the government to decrypt the content if they needed to. Around the 2000s with the rise of e-commerce, they dropped the export restriction because it was doing more harm than good. No one wanted to use so few bits in the encryption keys, but it was illegal at the time to write software which did.
A UUID’s 122 bits of randomness are exponentially more than the 56 bits DES offered. My original point being, all crypto is inherently brute forceable on an infinite timescale, but key length and implementation decisions are chosen to so that it would be computationally infeasible to brute force.
It’s not, though. And thinking that it is impossible is why DES, for example, was “translatable” by the NSA for decades. Never assume something is impossible just because it’s difficult.
Disabling index and making the names UUID would make the directory inviolable even if the address was publicly available.
Bet you could reuse/keep UUIDs for someone/stuff that gets updated and get that new data even if you “shouldn’t”.
It could work in theory but in practice there are always a billion things that go wrong IMO.
Not really sure what you mean by reusing UUIDs but theres nothing bad about using UUIDs in URLs for content you don’t want scrapped by bots. Sites like Google Photos are already are using UUIDs in the URL for the photos, and do not require any authentication to see the image as long as you have the URL. You can try this for yourself and copy the URL of an image and open it in a Private Browsing Window. Every so often someone realizes the actual image URL is public and think they’ve found a serious issue, but the reason why it isn’t is because of the massive key space UUID provides and that it would be infeasible to check every possible URL, even if it’s publicly available.
You point out the “vulnerability” yourself, sometimes (when it’s Google) it works as designed, but a less robust site could have the full access through a UUID for example and then someone shares an image with it, bam they have access to more than they should. The history is littered with bulletproof things like this ending up being used wrongly.
Security through obscurity never works.
It’s not security through obscurity in this case. The filenames can’t be obtained or guessed through brute force. At least not with current technology or processing power…
Security through obscurity is when you hide implementation details.
Saying that my suggestion is security through obscurity is the same as telling that ASLR is security through obscurity…
Until the psuedo random UUID generator can be reverse engineered. Makes me think of this video: https://youtu.be/o5IySpAkThg
Anyway, I think we’re on the same wavelength and both agree that the implementation as is isn’t production-ready to say the least ;)
Sounds like a good case for brute forcing the filenames. Just do the proper thing and don’t leave your cloud storage publicly accessible.
While proper security is better, you’re not gonna brute force UUIDs.
As long as you’re not rate limited, you absolutely could.
A UUID v4 has 122 bits of randomness. Do you know how long that would take to brute-force, especially with network limitations?
It taking a long time doesn’t make it an impossibility. The fact that it has a limit of 122 bits, in and of itself, makes the possibility of a bruteforce a mathematical guarantee.
By this logic, all crypto is bruteforcable, on a long enough timeline.
A 122 bit random number is 5316911983139663491615228241121378303 possible values. Even if it were possible to check 1 trillion records per second, it would take 168598173000000000 years to check all the UUIDs and get the info on all the users. Even if every human on earth signed up for the app (~8 billion people), and you wanted to just find any one valid UUID, the odds of a generating a UUID and that being valid in their DB is basically 0. You can do the math your self following the Birthday Paradox to determine how many times you would need to guess UUIDs before the probability that any one UUID is valid against a population of the whole world is greater than 50%.
You should read into the NSA’s Translator. Granted, it’s relatively outdated with shifting text algorithms, but for a very long time (about half a century), it was able to bruteforce any key, regardless of length, in under an hour.
I’m not familiar with NSA’s Translator, so any info would be appreciated.
I saw your other comment about DES, and it should be noted that DES was with a key length of 56 bits, and that was enforced precisely because the NSA could brute force it. It wasn’t even a secret they could brute force 56 bit encryption, and written into law. Back then, if you wanted to use more than 56 bit encryption in the United States, you had to provide a key escrow system to allow the government to decrypt the content if they needed to. Around the 2000s with the rise of e-commerce, they dropped the export restriction because it was doing more harm than good. No one wanted to use so few bits in the encryption keys, but it was illegal at the time to write software which did.
A UUID’s 122 bits of randomness are exponentially more than the 56 bits DES offered. My original point being, all crypto is inherently brute forceable on an infinite timescale, but key length and implementation decisions are chosen to so that it would be computationally infeasible to brute force.
For all practical purposes, it’s impossible.
It’s not, though. And thinking that it is impossible is why DES, for example, was “translatable” by the NSA for decades. Never assume something is impossible just because it’s difficult.
It is. It is practically impossible to guess the file names. You telling otherwise means you don’t have sufficient knowledge on the matter.
@01189998819991197253 @ConstantPain
Security isn’t binary, it’s a spectrum. You apply the level of security that is appropriate for each situation.
Of course it’s *possible* to brute force it, but by the same logic you could brute force jwt tokens, or api keys, or even ssl certs.
It’s literally *impossible* to apply “max security” to everything, so you have to prioritize.
What happened was unconscionable, but insisting uuid are mathematically breakable isn’t helpful, and can make it worse.
UUIDs are essentially random numbers, crypto schemes are not, they’re not comparable.
You cannot!
I cannot. But the bruteforce is a mathematical guarantee.
And has nothing to do with my proposition.
Can’t be done.