在SQL Server 2008中存储用户密码的推荐做法是什么？
我正在存储内部网的用户详细信息,并希望获得有关存储用户详细信息(如名称,密码和用户访问权限等)的最佳方法的建议.我正在考虑创建一个nvarchar列,然后在插入之前加密此文本桌子.
Ela*_*ich 56
存储密码的常用方法是在密码上使用哈希函数,但事先将其加盐.重要的是"加密"密码,以保护自己免受彩虹表攻击.
所以你的桌子看起来应该是这样的
._______._________________.______________.
|user_id|hash |salt |
|-------|-----------------|--------------|
|12 |adsgasdg@g4wea...|13%!#tQ!#3t...|
| |... |... |
检查给定密码是否与用户匹配时,应将salt连接到给定密码,并计算结果字符串的哈希函数.如果散列函数输出与hash列匹配- 它是正确的密码.
然而,重要的是要理解盐哈希的想法有一个特定的原因 - 防止任何有权访问数据库的人知道任何人的密码(反转哈希函数输出被认为是困难的问题).因此,例如,银行的DBA即使可以访问所有列,也无法登录到您的银行帐户.
如果您认为您的用户将使用敏感密码(例如他们的gmail帐户的密码)作为您网站的密码,您还应该考虑使用它.
恕我直言,它并不总是需要的安全功能.所以你应该考虑一下你是否想要它.
有关此机制的详细摘要,请参阅此文章.
更新:值得一提的是,为了获得额外的安全性来抵御针对个人密码哈希的目标攻击,您应该使用bcrypt,这可能是任意难以计算的.(但除非你真的害怕黑色的神秘男人瞄准你的特定数据库,我认为sha1足够好了.我不会为我的项目引入另外一个依赖于这个额外的安全性.那就是说,没有理由不使用sha1 100次,这会产生类似的效果).
敏感数据的加密很好.但是,使用密码时,您永远不需要知道原始值,并且由于加密的任何内容也可以被解密,因此您将这些信息置于被发现的危险之中.
相反,您应该保留密码的哈希值.此过程获取值并生成相当于非常复杂的校验和.鉴于该号码,无法返回原始密码,从而提高了此类信息的安全性.当您想知道某人是否给您正确的密码时,您可以散列他们给您的值并比较哈希值.
安全是一个复杂的话题.即使使用哈希,您最终也可能拥有一个存在严重安全漏洞的系统.如果团队中没有其他人已经拥有这种知识,那么获得安全顾问的帮助并不是一个坏主意.
这通常是这样做的方法。
您的应用程序将处理加密（以及可选的解密），数据库将仅存储密码。
我建议使用比过时的事实更强的东西 - MD5
大多数 .net 开发人员似乎喜欢使用 TDES
| 归档时间： |
|
| 查看次数： |
64669 次 |
| 最近记录： |