这种机制是否可以安全地验证用户身份?

时间:2015-03-19 09:53:37

标签: php security hash

我正在一个网站上工作,以了解有关网络编程的更多信息,并将其作为初创公司推出。我遇到的第一个问题是如何实现安全登录系统。目前我已经采取了一些措施,比如逃避密码,然后使用盐来对其进行散列。但我想知道以下机制是否安全,

  • 我将让用户输入用户名并继续检查用户是否输入了用户名(当文本框失去焦点或用于提交用户名的按钮时,也是为了防止列出用户名,通过在系统上设置cookie来阻止用户不正确的尝试,或者每次使用验证密码,一旦输入用户名,生病后将随机存储的盐发回给用户。
  • 使用输入的盐和密码,用户将散列密码并以表格
  • 发送
  • 我将通过比较哈希来验证密码

我认为这将是有益的,因为服务器端我不需要做任何处理,因此我不必担心DoS攻击,因为我读到某处使用像BCrypt这样的慢速散列会将网站暴露给DoS攻击。 此外,用户的密码永远不会通过网络进行通信,从而使人们可以安全地嗅探网络。

请指点我参考或任何可能有助于我安全实施的内容。考虑一下我,因为我还在开始学习,想知道你对它的看法,有什么可能的缺陷?什么必须是安全的策略。

UPDATE - 我得到的答案很多,通常都认为我认为这是SSL的替代方案;不,不是这样的。通过防止嗅探,我意味着保护,以防一些攻击者可能使用户使用SSL代理。 仅供参考 - https://security.stackexchange.com/questions/19616/why-is-it-possible-to-sniff-an-https-ssl-request

4 个答案:

答案 0 :(得分:3)

客户端哈希可以有其优势,但你不能没有服务器端哈希。在您的方案中,计算的哈希充当新密码。对数据库具有读访问权限的攻击者(SQL注入)将看到此哈希值并可以直接将其用作登录密码。

使用具有成本因子的慢哈希是必需的,通常它是在服务器端完成的,因为客户端语言较慢并且可以做更少的轮次。当然有人可以使用它来进行DoS攻击,但这也可以用于每个其他页面。密码的大小无关紧要(因为人们可以偶尔阅读),因为在第一轮之后只会散列哈希值。

如果您计划进行客户端哈希,请不要忘记在服务器上计算(快速)哈希值。而且你必须确保散列是在客户端正确完成的。更重要的是,您使用SSL发送凭据。

您可能会对Secure authentication: partial client-side key stretching…这个问题感兴趣。

修改

我将尝试总结客户端散列的重点。

  1. 具有salt和成本因子(BCrypt / PBKDF2 / SCrypt)的慢哈希算法是mandataory,这是唯一一个难以从哈希中检索原始密码的事情,如果密码很弱。可以在客户端执行此操作。
  2. 服务器端哈希也是必需的,以防止攻击者直接将存储的哈希值用作密码,如果他知道的话。哈希可以快速没有盐(SHA-256),因为输入(BCrypt哈希)具有足够的熵。如此强大的“密码”,包含60个字符,无法成功强制使用。
  3. 如果攻击者因为输入太强而无法破解快速SHA-256哈希,他可以尝试使用原始密码(来自字典)暴力破解。但要做到这一点,他首先必须计算缓慢的BCrypt哈希值,然后再计算快速的SHA-256哈希值。
  4. JavaScript 等客户端语言通常被解释,并且比编译代码慢得多,因此您可以在服务器上执行更少的回合(这会削弱安全性)。如果您有可能在客户端上运行本机代码,那么慢速哈希客户端就没有缺点。

答案 1 :(得分:0)

不,你不应该发送任何盐#39;给用户。 它可以被嗅到。

您基本上做的是发送类似于(csrf-)令牌的内容,可以使用一次。没错,但你似乎正在重新发明轮子。

答案 2 :(得分:0)

说真的,我认为你的解决方案只对黑客有利。如果我嗅到通信,我将逐渐获得用户名,盐和密码哈希。您必须通过网络发送所有这些值(用户名获取salt,密码哈希到auth尝试)。现在我可以直接在恶意登录请求中使用嗅探密码哈希或者在本地开始破解密码(用户通常拥有相同的密码以获得更多服务)。对身份验证尝试的所有检查和限制都不在游戏中,因为我不需要发送请求来猜测密码。取决于哈希算法,它或多或少会耗费时间。我认为网络嗅探是你不通过网络发送普通密码来计算的主要目的。

您可以使用TLS保护网络通信,但是在客户端上发送salt和hashing密码的所有内容都是不必要的。您只需将纯文本密码发送到服务器即可。但是,是的,在客户端上散列密码,如果你想要的话为什么不呢。你可以使用ie。如果您认为bcrypt是性能问题并且可能是DOS原因,那么sha1也会在服务器上。

用于通过不安全网络传输信息的协议的良好示例是OAuth 1.0a,甚至在其中您需要一些加密或TLS来传输消费者秘密。

如果我理解不正确,请告诉我。

答案 3 :(得分:0)

我想我唯一可以看到的缺点就是在低端移动设备上使用它。