example.com/profilepics/asdf-1234-zxcv-7890.jpg。用户ID必须保留多长时间，以防止任何人找到他们没有找到的用户照片被赋予链接了吗？
16个小写字母和0到9的小写字母是否提供合理的复杂性？我将其基于3616 = 8x1024，保守地估计100亿用户帐户会将空间减少到8x1014。以1000次猜测/秒的速度，需要25,000年才能找到一个帐户。除非我忽略了什么。
#1 楼
这完全取决于您所说的“安全”的含义。如果您唯一关心的是攻击者猜测URL，那么16个字母数字将提供大约8,000,000,000,000,000,000,000,000,000,000个可能的地址，这足以阻止随机猜测-按顺序为了使攻击者有50％的机会在一年中有1000名用户的网站上找到一张图片，他们需要每秒进行100万亿次尝试，足够的流量才能使甚至Amazon或Google之类的产品瘫痪。 br />
但是，URL泄漏还有其他方法：人们将其放入电子邮件或博客文章中，网络爬虫发现您没有充分保护的页面，等等。如果您确实需要保护某些内容，则需要将其置于与网站其他部分相同的安全级别。
个人而言，为了制作难以猜测的URL，我将使用GUID / UUID。搜索空间非常庞大，您不需要协调多个服务器之间的生成，并且大多数语言都有用于处理它们的标准例程。
评论
大多数GUID生成器不保证输出结果不可预测。因此，您应该从CSPRNG生成16个随机字节，而不要使用标准的GUID生成器。
– CodesInChaos
2014年5月19日上午10:10
@R ..不一定，这取决于您的GUID或UUID实现。但是，我认为这些天大多数时间可能是随机的，但可能不是安全的随机（因此可能是可预测的）。要记住的是目标是“独特的”，而不是“不可预测的”，因此好的实现满足“独特的”，而且也许也是“不可预测的”。
– Tim S.
14年5月19日在13:43
@R .. UUID不是加密实体，仅在所有人都同意的情况下它们才是唯一的。好处是，对于按预期使用UUID的任何应用程序，无论其他人是否复制或重复使用UUID都无关紧要，只有两个系统随后必须共享数据时，这才是问题。如果您必须与故意破坏UUID系统的人共享数据，则可能会遇到更大的问题。
–aaaaaaaaaaaa
2014年5月19日17:33
@R ..您不正确； GUID被记录为唯一性而非随机性的来源。类型4 GUID是随机的，但是不能保证随机性是加密强度，实际上不是。更笼统地说：GUID并非旨在成为任何安全系统的一部分；在安全系统中使用它们是“不合规定的”使用，因此是一个非常糟糕的主意。
–埃里克·利珀特
2014年5月19日17:43
@R ..：GUID系统故意设计为无法抵抗恶意使用。就像一个停车牌；停车标志不会强迫您停车。如果有人因为恶意并且乐于引起事故而想忽略它并穿越十字路口，那么停车标志不会阻止他们。 GUID是确保唯一性的合作系统；假定所有各方都是非敌对的。
–埃里克·利珀特
2014年5月19日17:45
#2 楼
也许不是您问题的答案，但是如果您想“隐藏”个人资料图片在网站上的位置，则可以将图片作为数据URI嵌入。您可以在服务器上对图片进行base64编码并将字符串嵌入到您的网站中，而不是暴露任何图像路径。
请参见http://css-tricks.com/data-uris/和http://css-tricks.com/examples / DataURIs /以获取描述和演示。
评论
@FaridNouriNeshat，数据URI不限于http URI的2000个字符。如果需要支持Internet Explorer 8或更早版本，则限制为32k；否则，最大值为32k。如果您可以要求IE9或更高版本，则没有限制。
–马克
2014年5月19日上午10:20
@Mark你是对的。抱歉，我将此与另一种方法混淆了。
–法里·诺里·内沙特（Farid Nouri Neshat）
2014年5月19日10:46
这有一个问题：带宽。缓存在这里无法工作，因此您最终会更频繁地发送相同的30KiB映像，这转化为金钱和性能。
– Darkhogg
2014年5月19日上午10:47
当需要时，这些圣烟很酷！
–owenfi
2014年5月19日在21:05
#3 楼
既然您已经启动了保管箱，那么我认为至少可以给出一个为什么这样做不是个好主意的原因：Dropbox在纳税申报单最终在Google上后会禁用旧的共享链接。 />
据报道，Box中也存在该漏洞，该漏洞会影响包含超链接的共享文件。该公司昨天在确认该漏洞时指出：“ Dropbox用户可以共享指向其Dropbox中任何文件或文件夹的链接”：
只有拥有链接的人才能访问通过链接共享的文件。 。但是，在以下情况下，文档的共享链接可能会无意间泄露给意外的收件人：
Dropbox用户共享指向包含第三方网站超链接的文档的链接。
用户或链接的授权接收者单击文档中的超链接。
此时，引荐来源标头会公开指向第三方网站的原始共享链接。
有权访问该标头的人（例如第三方网站的网站管理员）可以访问共享文档的链接。
基本上是考虑到有多少用户使用URL，这很容易导致URL意外泄漏。如果您的用户对此有所了解并避免了这些问题，那么我认为它是相当安全的，但这是一个很大的假设。
评论
谢谢，这是牢记该主题的一个很好的观点。就我而言，它只能通过应用程序私下使用，因此普通用户不太可能首先拥有该URL来共享它（缺少对API的反向工程）。
–owenfi
2014年5月19日在19:56
@owenfi在这种情况下，假设您使用足够大的地址空间和安全的随机算法来创建URL，我认为我们可以认为这是相当安全的。
– Voo
2014年5月19日在20:53
Voo引用的文章包含指向该问题的另一篇文章的链接：theregister.co.uk/2011/05/08/file_hosting_sites_under_attack“在2011年，研究人员发现可以通过猜测URL来访问共享文件。”
– WGroleau
2014年5月20日下午2:10
@WGroleau应该指出，在该链接中，所有给定的示例都是以一种或另一种方式损坏的系统。损坏的系统都没有使用大的搜索空间和安全的随机生成器。我的意思是真的..顺序URL？因此，我发现它的适用性不如给定的链接，后者显示了系统的固有缺陷（仅用于某些用途），而不仅仅是实现失败的问题。尽管它表明人们将尝试利用这种系统，但最好确保它是合理的！
– Voo
2014年5月20日20:42
#4 楼
其他答案通常是好的，但另一个考虑因素是运输。如果您使用纯http或任何其他非加密协议（或通过电子邮件发送url），则从安全角度考虑，您传输和接收的所有数据（包括这些url）都应视为完全公开的。很大一部分用户（是否有统计信息？）都位于不加密的公共wifi接入点上，这种网络的活动url /图像抓取很常见。评论
啊哈，我忽略了这一点！谢谢！幸运的是，就我的服务而言，SSL是强制性的。
–owenfi
2014年5月19日19:57
#5 楼
正如其他人提到的那样，特定图像的URI迟早都会泄漏出去，无论它持续了多长时间或令人费解。如果您愿意将登录的用户限制在查看范围内，则可以使用.../image/profile.php?u=12345来显示用户12345的图像，而无需将照片的直接URI传递给公众。假定随机的人（未登录）不会从profile.php得到任何回报。请注意，没有什么可以阻止已登录的用户保存该图像（特别是如果它已缓存）并传递该图像。可以使用缓存控制标头等来完成某些事情，或者将图像放入Flash等中，但是如果可以在某人的浏览器上查看图像，则只要有足够的工作，就可以抓取并保存它。评论
例如，您无法采取任何措施阻止用户进行屏幕截图！ :)
–nicodemus13
2014年5月20日15:04
@ nicodemus13，这就是流媒体公司尝试在硬件级别实施DRM的原因。
–伊凡·科尔米切克（Ivan Kolmychek）
16年7月27日在9:40
#6 楼
您的方案存在的问题是，您的URL的众多用户可能不会全部猜测它们都包含敏感信息。问题的一部分是您可能不知道用户群的大小。对于这些URL，用户包括您认为是用户的人。
他们的浏览器插件/附加组件/扩展。
关于任何第三方内容您网站上的广告（分析，社交插件等）可能会以一种或另一种方式告知第三方有关的网址。
看似随机的网站将其视为引荐来源网址（您真的知道用户通过浏览器插件会在用户的网站上造出什么奇怪的额外链接吗？）。
经验证据是广告宣传为等同于密码的仅HTTPS URL被Google反复索引，例如对于无密码的比特币在线钱包Instawallet（请注意，他们已经破产了，以至于他们甚至不再提供有效的SSL证书了。）
评论
谢谢，这里指出了一些非常好的案例。看起来像在网站上推广之前，我需要将其放在auth之后。 （目前，它仅在app-api中，因此第三方将在某种程度上限于联网模块，也许第三方工具会观察我的文档目录。）
–owenfi
2014年5月21日在1:56
人们甚至可能将整个URL输入到Google搜索栏中，因此会将URL公开给Google。
–马丁·乌丁
2014年5月21日在12:52
#7 楼
上面提到的每个人都添加了几个要点，似乎错过了其中的一些。由于人们意识到密码，无意中公开URL的可能性比公开密码要高。
Facebook之类的网站使用的CDN URL非常复杂，以至于没人能猜到，但是从安全角度来看，它们似乎具有风险，因为当用户更改隐私设置时，无法撤销访问权限。某些网站，包括后端具有亚马逊网络服务s3存储的网站，都使用带有时间戳的签名URL，该URL会定期进行验证。
Google缓存！搜索引擎可能会爬过所谓的私人图片。用奇怪的东西进行搜索，只会带回来自Facebook CDN的结果，您会感到惊讶。
评论
我特别喜欢第2点。此文件已在现已停用的“朋友”系统中用于个人资料图像。删除访问的观点是一个很好的考虑因素（我想这与保存图像的人没有太大不同）。
–owenfi
17年5月16日在20:15
@owenfi我同意这一点。与保存图像没有太大区别，但是存在从浏览器历史记录，缓存等中获取详细信息的可能性。
– hax
17年5月24日19:31
评论
好吧，AWS会对用户文件进行这种处理（如果我没记错的话，它是128位随机名称），因此您可以假定它“足够安全”，如实践中所示。@owenfi生成128位以上的值，您就可以了。对于您的特定情况和应用，这已经足够了。
无论如何，这是没有意义的。密码，令牌，证书，到底是不是什么安全性呢？正确使用时的说法并不适用于方法。
此问题等效于“我应该如何选择安全密码？”。我什么都没看到。
这与上周的Dropbox漏洞（security.stackexchange.com/questions/57436/…）是相同的-这些是公共网址，可以被抓取并被索引，用户可以共享/发布自己的链接，等等。