安全令牌URL - 它有多安全？代理认证作为替代？ [英] Secure Token URL - How secure is it? Proxy authentication as alternative?
问题描述
我知道它是安全令牌URL，maby还有另外一个名字。但是我认为你们都知道。
如果你想限制内容交付给某个客户端，那么你已经提前递交了一个特定的url。
你需要一个秘密标记，将它与你想保护的资源连接起来，并且当客户端在你的一台服务器上请求这个URL时，从请求中收集的信息重新构建，并比较哈希。如果它相同，内容交付，否则用户被重定向到您的webseite或其他东西。
你也可以在时间戳中放置一段时间在网址上居住，或者包括用户的IP地址，以限制其连接。
亚马逊（S3和Cloudfront）使用该技术，Level 3 CDN ，Rapidshare等等。它也是http摘要认证的基本部分，尽管它有更进一步的链接失效和其他的东西。
这是一个指向亚马逊文档，如果你想知道更多。
现在我对这种方法的担心是，如果一个人破解了你的链接的一个标记，攻击者就会得到你的标记纯文本，并且可以在你自己的名字上标记任何URL。
或者更糟糕的是，在亚马逊的情况下，在管理范围内访问您的服务。
当然，字符串哈希值通常很长。你可以包含很多东西，甚至通过向请求中添加一些不必要的数据来强制数据具有最小长度。 Maby在URL中使用了一些伪变量，并使用随机数据填充它。
因此，蛮力攻击破解sha1 / md5或任何你使用的hash相当困难。但协议是开放的，所以您只需填写秘密令牌的空白处，并使用来自请求者的已知数据填充其余部分。而今天的硬件非常棒，可以以每秒几十兆的速度计算md5。这种攻击可以分布到计算云中，并且不限于诸如每分钟通过登录服务器进行10次尝试等等，这使得哈希方法通常非常安全。现在有了亚马逊EC2，你甚至可以在短时间内租用硬件（用自己的武器击败他们！）所以你觉得怎么样？我的担忧是有根据还是偏执？
但是，我正在设计一个对象存储满足特殊需求的云（集成媒体转码和流传输等特殊传输方法）。现在，level3引入了另一种安全令牌URL的方法。它目前是测试版，只对需要它的客户开放。他们称之为代理认证。
会发生什么情况是内容交付服务器向您（客户端）设置中指定的服务器发出HEAD请求，并模仿用户请求。所以传递相同的GET路径和IP地址（与x_forwarder一样）。您使用HTTP状态代码进行响应，通知服务器与内容交付有关。
您也可以在此引入一些安全令牌过程，而您也可以对它施加更多的限制。像让一个URL只被请求10次左右。
它显然带来了很大的开销，因为额外的请求和计算发生，但我认为它是合理的，我没有看到任何警告。你可以基本上将你的问题重新定义为：需要多长时间才能保证安全。
>要回答这个问题，可以考虑可能的字符数（字母数字+大写字母已经是每个字符62个选项）。其次确保秘密令牌是随机的，而不是在字典或其他东西。然后，例如，如果您需要一个长度为10个字符的秘密令牌，则需要62 ^ 10（= 839.299.365.868.340.224）次暴力尝试（最坏情况;平均情况会是当然的一半）。我真的不会对此感到害怕，但如果你是这样的话，你总是可以确保秘密令牌至少有100个字符长，在这种情况下，它需要62 ^ 100次尝试暴力（这是三行我的终端）。
结论：只需取一个足够大的标记，就足够了。
课程代理身份验证确实可以为您的客户提供额外的控制，因为他们可以更直接地控制谁可以查看而不是，并且这也会例如破坏电子邮件聊天。但我不认为暴力强化需要足够长的时间才能成为关注点。
I know it as secure-token URL, maby there is another name out there. But I think you all know it.
Its a teqniuque mostly applied if you want to restrict content delivery to a certain client, that you have handed a specific url in advance.
You take a secret token, concatenate it with the resource you want to protect, has it and when the client requests the this URL on one of your server, the hash is re-constructed from the information gathered from the request and the hash is compared. If its the same, the content is delivered, else the user gets redirected to your webseite or something else.
You can also put a timestamp in the has to put a time to live on the url, or include the users ip adress to restrict the delivere to his connection.
This teqnique is used by Amazon (S3 and Cloudfront),Level 3 CDN, Rapidshare and many others. Its also a basic part of http digest authentication, altough there is it taken a step further with link invalidation and other stuff.
Here is a link to the Amazon docs if you want to know more.
Now my concerns with this method is that if one person cracks one token of your links, the attacker gets your token plain-text and can sign any URL in your name himself.
Or worse, in the case of amazon, access your services on an administrative scope.
Granted, the string hashed here is usually pretty long. And you can include a lot of stuff or even force the data to have a minimum length by adding some unnecessary data to the request. Maby some pseudo variable in the URL that is not used, and fill it up with random data.
Therefore brute force attacks to crack the sha1/md5 or whatever you use hash are pretty hard. But protocol is open, so you only have to fill in the gap where the secret token is and fill up the rest with the data known from the requst. AND today hardware is awesome and can calculate md5s at a rate of multiple tens of megabytes per second. This sort of attack can be distributed to a computing cloud and you are not limited to something like "10 tries per minute by a login server or so" which makes hashing approaches usually quite secure. And now with amazon EC2 you can even rent the hardware for short time (beat them with their own weapons haha!)
So what do you think? Do my concerns have a basis or am I paranoic?
However,
I am currently designing an object storage cloud for special needs (integrated media trans coding and special delivery methods like streaming and so on).
Now level3 introduced an alternative approach to secure token urls. Its currently beta and only open to clients who specifically request it. They call it "Proxy authentication".
What happens is that the content-delivery server makes a HEAD request to a server specified in your (the client's) settings and mimics the users request. So the same GET path and IP Address (as x_forwarder) is passed. You respond with a HTTP status code that tells the server to go a head with the content delivery or not.
You also can introduce some secure-token process into this and you can also put more restrictions on it. Like let a URL only be requested 10 times or so.
It obviously comes with a lot of overhead because additional request and calculations take place, but I think its reasonable and I don't see any caveats with it. Do you?
You could basically reformulate your question to: How long a secret token is needed to be safe.
To answer this consider the number of possible characters (alphanumeric + uppercase is is already 62 options per character). Secondly ensure that the secret token is random, and not in a dictionary or something. Then for instance if you would take a secret token of 10 characters long, it would take 62^10 (= 839.299.365.868.340.224 )attempts to bruteforce (worstcase; average case would be half of that of course). I wouldn't really be scared of that, but if you are, you could always ensure that the secret token is at least 100 chars long, in which case it takes 62^100 attempts to bruteforce (which is a number of three lines in my terminal).
In conclusion: just take a token big enough, and it should suffice.
Of course proxy authentication does offer your clients extra control, since they can way more directly control who can look and not, and this would for instance defeat emailsniffing as well. But I don't think the bruteforcing needs to be a concern given a long enough token.
这篇关于安全令牌URL - 它有多安全？代理认证作为替代？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
