我正在为我正在组合的应用程序进行基本用户身份验证,而且我没有太多安全经验.
这就是说,我理解在数据库中将(盐渍)密码哈希作为blob进行盐析/存储的做法(和必要性),而不是密码(加密或否).我已经实现了这一点.
通过对用户名进行腌制/散列并将散列存储在数据库中,而不是明文(或加密)中的用户名,是否可以获得任何东西？令我感到震惊的是,这将使得确定哪些用户可以使用数据库进行身份验证来访问系统变得更加困难.
由于让某人难以破解用户帐户的密码至关重要,因此增加确定哪些用户可行的难度也不合理吗？
编辑:我可能使用的某些语言不是100%正确:随意纠正:-)
编辑2:我改变了我的第一个点,表示腌制哈希 - 感谢大家指出我错过了这个:-)
Edit3:删除了表示我正在加密/解密密码的措辞.我正在使用盐渍哈希并将其存储在数据库中 - 感谢Scotty指出这一点.
评估您所服用材料的灵敏度非常重要.为了深入挖掘,我将提供一些用例.
场景1:社交网络应用程序
您所有用户的互动都发生在公众场合.他们的电子邮件地址将用作他们的用户名.用户名不被视为私有,因为他们的名字出现在他们的所有帖子中.用户可以搜索用户名和/或启用电子邮件邀请.
判决 - 哈希=糟糕
场景2:电子商务站点
用户可能会也可能不会参与公共互动(例如评论,评论).使用电子邮件地址作为用户名可能是一个坏主意,因为通过使用密码恢复,受感染的电子邮件帐户意味着您网站上的用户帐户被盗用.
这里有很多灰色区域,通常是为了"方便"而被利用.如果您的网站使用电子邮件作为用户名,则存储运送历史记录和信用卡号; 受损的电子邮件可能意味着您的用户会遇到很多身份盗用问题.
在这种情况下,使用用户名不是用户电子邮件地址的策略可能是个好主意.散列电子邮件不会增加任何价值.
注意:我在看Amazon.com.
判决:共同实践!=良好实践
场景3:色情网站
使用户名为假名,登录名为用户的电子邮件地址.他们可能会倾向于谈论内容,并且不一定希望他们的名字出现在谷歌的黑莓网站的结果上.
假设这里最糟糕的.如果您的数据库被黑客攻击,那么暴露您的用户身份可能会造成无法弥补的伤害.不要以为这可能发生在你身上吗？看看这篇文章.
他们的用户帐户不仅遭到黑客攻击并且密码暴露,而且很多用户很有可能在他们的电子邮件帐户中使用相同的密码.现在,他们的信息将匿名发布在PasteBin上,供全世界查看.更糟糕的是,他们中的大多数人可能甚至不知道这已经发生了.
通过简单地对用户名和密码进行哈希处理,他们就可以为自己和用户节省很多麻烦.
结论:无论是否将其用作用户名,都要对电子邮件地址进行哈希处理.
场景4:银行
不言而喻,银行/金融网站不应该免费.
安全性可以增加:
使用电子邮件地址以外的用户名
通过要求数字和字母强制使用唯一的用户名
哈希密码
需要2点身份验证(如果用户的电子邮件密码被泄露)
哈希电子邮件地址
等等...
应该不遗余力地保护您的用户,因为如果不这样做,就意味着您正以赌博为生.
结论:
适用于所有站点的安全性没有硬性规定.在某些情况下,用户名是公开的,因此散列它不会增加任何价值.在其他情况下,不散列它可能会造成无法弥补的伤害.如果您最终开发了一个可以使用户名/电子邮件哈希变得有用的网站,这是一个很好的方法.
哈希用户名
为用户生成独特的盐
使用salt散列密码
将密码与salt一起存储在数据库中
通过不用盐对用户名进行散列,可以避免鸡/蛋问题.除非您对所有用户名使用静态salt.
请记住,通过阅读代码可以找到所有用户帐户的静态盐.一旦找到静态盐,当采用彩虹表攻击时,它基本上是无用的.如果您对密码加密,则生成动态salt并将其与用户凭据的其余部分一起存储在数据库中.
如果您想要简单的硬/快速规则,请记住一些好的假设:
假设您的数据库可能在某些时候受到损害
假设您的源代码在某些时候会受到损害
假设您的用户的电子邮件在某些时候会受到损害
假设您的用户愚蠢并使用与他们用于电子邮件的网站相同的密码
假设黑客是聪明/机智和财务驱动的.
如果您选择存储敏感/私人数据,那么进行额外步骤可能会在将来为您节省公关/法律噩梦.
更新:一篇关于种子哈希的有趣文章刚出现在Coding Horror上.
简短的回答:很可能没有.
答案很长:你的情况似乎缺乏关键"我的用户名因为...而敏感"这引出了一个问题:"为什么？保护用户名会解决的具体,可证明的问题是什么？"
没有这个问题,你所描述的是与安全相关的开发(以及整个开发)的常见缺陷:想出一些想法来保护或混淆系统的某些部分,然后寻找使用它的理由.与软件开发中的任何内容一样,除了明确的问题只能通过使用特定工具解决之前,您应该避免做除了确切需要之外的任何事情.
额外提示(免费!): 加密密码哈希值.普通的哈希远不那么安全.
京公网安备 11010802040832号 | 京ICP备19059560号-6 