传递散列密码时有哪些安全问题？
我的网页上有一个 Silverlight 控件，并且希望将用户名和散列密码作为 InitParams 的一部分传递给该控件。
这样做有哪些安全问题？
用户必须登录才能访问此页面。 但是，我猜测浏览器可能会使用 Silverlight 控件缓存页面，这将缓存用户名和散列密码。
这让我想到一个更具体的问题：是否有 HTML 元标记告诉浏览器不要缓存页面？
I have a Silverlight control on a web page and would like to pass the username and the hashed password to this control as part of the InitParams.
What are the security concerns with doing this?
The user has to log in to get to this page. However, I'm guessing that the browser might cache the page with the Silverlight control and this would cache the username and hashed password.
This brings me on to a more specific question: Is there a an HTML meta tag that tells a browser not to cache a page?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
安全性：首先考虑恶意用户可能对哈希密码的潜在用途（包括与其他存储的哈希值进行比较）。
缓存：是的，有一个元标记，但除非必须，否则不应该使用它； 最好设置 HTTP 标头
Security: Think first about potential uses a malicious user might have for the hashed password (including comparison with other stored hashes).
Caching: Yes there is a meta tag, but you shouldn't use it unless you have to; better to set the HTTP headers
如果攻击者可以获取散列密码，他可能会使用 彩虹桌。 彩虹表基本上是一个巨大的数据库，其中包含达到一定大小的所有可能密码，并通过哈希值进行索引。 我认为这是最终的速度与空间的权衡。 对于最多 7 个字符（仅包含小写字母和数字）的密码，彩虹表可以容纳几 GB。 对于较长的密码（或字符限制较少的密码），所需的大小确实呈指数增长。
要击败此攻击，您需要对哈希值加盐。 加盐意味着您在对密码进行哈希处理之前向密码添加随机盐值。 该盐可以未加密地存储在哈希值旁边。 由于每个密码都用另一个随机盐进行哈希处理，因此彩虹查找表变得毫无用处。 彩虹表无法考虑所有可能的盐值，因为所需的数据库大小随着盐大小呈指数增长。
即便如此，仍然可以通过暴力破解来找到与 salt+hash 匹配的弱密码。 这可以通过对密码使用一些质量控制启发法来解决（最小长度、混合某些字符类型，如小写/大写/数字/其他，而不仅仅是末尾的 1...）。
总而言之，我想说暴露哈希值的安全风险足够大，所以你最好避免它。
If an attacker can get at the hashed password, he could potentially reverse it by using a rainbow table. A rainbow table is basically a huge database of all possible passwords up to a certain size, indexed by their hash. I think of it as the ultimate speed-space trade-off. For passwords of up to 7 characters, containing only lower case letters and numbers, the rainbow table can fit in a few gigabytes. For longer passwords (or ones with less character restrictions) the required size does rise exponentially.
To defeat this attack, you need to salt the hashes. Salting means that you add a random salt value to the password before hashing it. This salt can be stored unencrypted next to the hash. Since each password is hashsed with another random salt, the rainbow lookup table becomes useless. Rainbow tables cannot consider all possible salt values because the required database size rises exponentially with the salt size.
Even then, weak passwords matching the salt+hash could still be found with brute force. This can be fixed by using some quality-control heuristics on the password (minimal length, mixes certain character types like lowercase/uppercase/digits/other, not just a 1 at the end...).
All in all, I'd say the security risks of exposing the hash are big enough that you're better of avoiding it.
我的问题是，控件可以使用散列密码做什么？ 它似乎没有任何有用的目的，那么为什么它被传递给控件呢？
密码经过哈希处理，使得通过计算无法恢复原始密码。 因此，假设哈希值处理正确，那么就不存在暴露它的风险。 但是，控件认为它需要散列密码的事实让我感到怀疑。
My question would be, what can the control do with the hashed password? It doesn't seem like it could serve any useful purpose, so why is it passed to the control?
A password is hashed to make it computationally infeasible to recover the original password. So, assuming the hash was done properly, there's no risk in exposing it. But, the fact that the control thinks it needs the hashed password makes me suspicious.
请记住，MD5 散列已被暴力攻击破解，因此公开散列密码并不是 100% 安全，但在大多数情况下，这可能不是问题，特别是如果您使用一些更强的散列算法。
Keep in mind that MD5 hashing has been cracked by brute force attacks, so having a hashed password in the open is not 100% secure, but for most cases it may be a non issue especially if you use some stronger hashing algorithm.