我正在从事一个必须具有身份验证(用户名和密码)的项目
它还连接到一个数据库,所以我想我应该把用户名和密码存储在那里。但是,如果密码只是数据库表中的一个文本字段,这似乎不是一个好主意。
我使用c#并连接到2008年的快速服务器。谁能建议(用尽可能多的例子)存储这类数据的最佳方法是什么?
附:如果有一个好的理由,我可以接受这个信息不存储在数据库中的想法
如果你不需要反向哈希,我会MD5/SHA1密码。当用户登录时,您只需加密给定的密码并将其与哈希进行比较。在这种情况下,哈希冲突几乎是不可能的,除非有人获得了对数据库的访问权,并看到了他们已经发生冲突的哈希。
在你的场景中,你可以看看asp.net会员,这是一个很好的做法,存储用户的密码作为散列字符串在数据库中。您可以通过将散列后的传入密码与存储在数据库中的密码进行比较来验证用户。
所有东西都为此目的而构建,检查asp.net的会员
你是正确的,将密码存储在明文字段中是可怕的的想法。然而,就位置而言,对于你将要遇到的大多数情况(老实说,我想不出任何反例),将密码的表示存储在数据库中是正确的事情。通过表示,我的意思是你想要使用salt(每个用户都应该不同)和安全的单向算法来散列密码,并存储那,丢弃原始密码。然后,当您想要验证密码时,将该值哈希(使用相同的哈希算法和salt),并将其与数据库中的哈希值进行比较。
所以,虽然你在思考这个问题是一件好事,这是一个好问题,但这实际上是这些问题的副本(至少):
为了进一步澄清这一点,简单地哈希密码并存储它的危险在于,如果入侵者掌握了你的数据库,他们仍然可以使用所谓的彩虹表来“解密”密码(至少是那些显示在彩虹表中的密码)。为了解决这个问题,开发人员在密码中添加了盐,这样做的话,彩虹攻击就变得不可行的了。请注意,一个常见的误解是简单地为所有密码添加相同的唯一的长字符串;虽然这不是可怕的,但最好为每个密码添加唯一的盐分。阅读这篇文章了解更多。
作为一个密钥加固的咸散列,使用安全算法,如sha-512。
最好的安全实践是根本不存储密码(甚至不加密),而是存储加密密码的咸散列(每个密码具有唯一的盐)。
这样(实际上)就不可能检索明文密码。
< >强背景 你从来没有……真的……需要知道用户的密码。
< >强散列: 通过强哈希函数存储哈希(单向加密)的用户密码。 搜索“c#加密密码”;
请参阅在线SHA1哈希创建者以了解哈希函数产生的内容(但不要使用SHA1作为哈希函数,使用更强的函数,如SHA256)。
现在,散列密码意味着您(和数据库窃贼)不应该能够将散列反转回原始密码。
如何使用: 但是,如何使用存储在数据库中的这个混合密码呢?< / p > 当用户登录时,他们会给你用户名和密码(在原始文本中) 您只需使用相同的哈希码哈希输入的密码,以获得存储的版本
因此,比较两个散列密码(用户名的数据库散列和输入的&散列密码)。你可以分辨出他们输入的东西。匹配“原始用户输入的密码”;通过比较它们的哈希值。
额外学分:
是的…是的,他们可以。
参见“如何用salt散列数据”;c#示例(已存档)
我可能有点跑题了,因为你提到了用户名和密码的需要,我对这个问题的理解也不是最好的,但是OpenID值得考虑吗?
如果您使用OpenID,那么您最终根本不存储任何凭据,如果我正确理解该技术,用户可以使用他们已经拥有的凭据,从而避免了创建特定于应用程序的新身份的需要。
但是,如果所讨论的应用程序纯粹用于内部使用,则可能不适合
RPX提供了一种将OpenID支持集成到应用程序中的好方法。
我强烈推荐阅读文章足够的彩虹表:你需要知道的关于安全密码方案[死链接,在互联网档案馆复印]和如何安全存储密码。
很多程序员,包括我自己,认为他们理解安全和哈希。可悲的是,我们大多数人就是不这样做。