按照RFC 4122生成的 UUID有几个“版本”；以 xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx 形式的 UUID（十六进制），然后：

• 如果 8 ≤ N ≤ b 且 M=1 或 M=2，则 UUID 标识生成它的机器和生成它的时间。
• 如果 8 ≤ N ≤ b 且 M=3 或 M=5，则使用加密散列函数确定性地生成 UUID。
• 如果 8 ≤ N ≤ b 且 M=4，则 UUID 是随机的（具有 6 个固定位和 122 个随机位）。

如果 UUID 不满足任何这些约束，则它不是根据 RFC 4122 生成的。但即使满足约束，也不能保证遵循 RFC，或者随机生成器是一个好的.

我不知道 S3 对 UUID 做了什么。

即使 UUID 是适当随机的，这会使 URL 不可猜测，保护对仅使用 URL 的资源的访问也是一个坏主意。URL 往往会以多种方式泄露：在电子邮件或聊天中共享、在浏览器历史记录和书签列表中散布、意外复制，或者更糟糕的是，作为链接留在作者打算保密但没有身份验证的页面中，以及被谷歌收录。

如果您想保护对 Web 上资源的访问，请不要依赖 URL 被保密。添加认证机制。即使是普通的旧密码身份验证也是对不可猜测的 URL 的巨大改进——浏览器甚至人们都知道他们不应该共享密码，而 URL 通常是公共知识。

显然，100% 正确的解决方案是不让文件公开可读和可写。这在这里不受您的控制，但也不是绝对必要的。

服务器的设置方式类似于incoming30-40 年来在 FTP 服务器上设置文件夹的方式：您可以cd进入该目录并创建/写入文件，并读取您可以打开的任何文件，但您无法列出目录的内容（并且可选地，您可以创建和写入任何文件，但不能覆盖现有文件）。

假设无法猜测文件名，这是安全的，因为您在不知道文件名的情况下无法做很多事情。UUID 有 128 位，但您可以使用任何其他大小相同或更大的随机文件名（或 160 位随机名称，如果您认为 128 位不够用）。
虽然理论上可以猜测一个随机的 128 位数字（甚至有可能两个文件名会意外发生冲突），但考虑到访问文件所需的时间，这种事情发生的可能性非常小通过网络（这严重限制了您每秒可以执行的操作数）。这与某人从被盗密码数据库中暴力破解哈希值大不相同，攻击者通常每秒尝试几亿次哈希值。
你可能更有可能死于被流星击中，而不是在你的生活中看到这种情况。

此外，一个快速的谷歌说 S3 支持文件夹，所以如果你处于极度偏执模式，你可以创建一个带有 UUID 名称的文件夹并将你的 UUID 命名的文件放在那里。有人必须正确猜测 256 位数字才能访问文件，您可以确定这在您的一生中不会发生。

有人随机猜测 v-4 UUID 的机会非常小。它太小了，不值得认真考虑。

看看数学。

以下等式显示产生 50% 正确匹配概率所需的猜测次数 (n) 为 2.71 quintillion。

n ≈ 0.5+sqrt(0.25+2*ln2*(2^122))
  ≈ 2,714,922,669,395,445,248
  ≈ 2.71 × 10^18

让我们将匹配的概率 (p) 增加到十亿分之一。

Let: p = 1/(1 billion) = 0.000000001
UUID   ≈ sqrt(2*2^122*ln(1/(1-p)))
       ≈ 103,120,461,418,554
       ≈ 103.1 × 10^12

即，要进行大约 103 万亿次猜测。

考虑到这些可能性，以及设计黑客攻击所需的计算能力，有人随机访问相关 UUID 的可能性是如此之低，以至于失去任何过夜都是不值得的。

Wikipedia 对模型和 UUID 在数据库键中的使用进行了深入的描述。

始终假设任何可寻址的网络都是可破解的。但是由于您的文件将有效地“不公开”并且使用 UUID 模型是半私有的，因此应该足以使它们几乎无法访问。

这是一个非常古老的帖子，但会有人遇到这个，因为它仍然出现在谷歌搜索中。这里给出的大多数答案都是错误的。您不应将 UUID 用作安全机制。“如何保护 S3 中的文件”问题的答案是使用 S3 预签名 URL。

请参阅此处的文档：https ://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html

您不应该在公共 S3 存储桶中存储您不希望全世界每天都看到的任何内容。我什至不会提及这为您打开的潜在滥用案例 - 如果您被 reddit 组无休止地拖钓，请考虑大型对象的数据传输费用。