我正在一个网站上工作，以了解更多关于web编程的信息，并将其作为一个初创公司推出。我遇到的第一个问题是如何实现安全登录系统。目前，我已经采取了一些步骤，比如转义密码，然后使用salt对其进行哈希。但我想知道以下机制是否安全，
- 我会让用户输入用户名，并不断检查用户是否输入了他的用户名（当文本框失去焦点或提交用户名的按钮时，也为了防止列出用户名——如果多次尝试不正确，或者可能每次都不正确地使用captcha，我会在系统上设置cookie来阻止用户），一旦输入用户名，我会向用户发送随机存储的salt
- 使用输入的salt和密码，用户将散列密码并以表单形式发送
- 我将通过比较哈希值来验证密码
我认为这将是有益的，因为服务器端我不必做任何处理，因此我不必担心DoS攻击，因为我在某个地方读到，使用一些缓慢的哈希（如BCrypt）会使网站暴露于DoS攻击。此外，用户的密码永远不会通过网络进行通信，从而使其免受网络嗅探者的攻击。
请给我指一些参考资料或任何可以帮助我安全实施的东西。想想我吧，因为我还没有开始学习，我想知道你怎么看，可能有什么缺陷？以及什么必须是安全的战略。
更新- 我得到的许多答案，通常都认为我认为这是SSL的替代方案；不，事实并非如此。我所说的防止嗅探是指在某些攻击者可能让用户使用SSL代理的情况下提供保护 仅供参考-https://security.stackexchange.com/questions/19616/why-is-it-possible-to-sniff-an-https-ssl-request
客户端哈希有其优点，但离不开服务器端哈希。在您的场景中，计算出的哈希充当新密码。对数据库具有读取访问权限（SQL注入）的攻击者将看到此哈希，并可以直接将其用作登录密码。
使用带有成本因子的慢速哈希是强制性的，通常是在服务器端完成的，因为客户端语言速度较慢，可以进行较少的循环。当然，有些人可以使用它进行DoS攻击，但这也可以在其他页面上进行。密码的大小并不重要（正如人们可以在本地阅读的那样），因为在第一轮之后，只有散列才会被散列。
如果您计划在客户端进行哈希，请不要忘记在服务器上计算（快速）哈希。您必须确保，散列是在客户端正确完成的。更重要的是，您使用SSL来发送凭据。
安全身份验证：部分客户端密钥拉伸…可能会引起您的兴趣。
编辑：
我将尝试总结客户端哈希的要点。
- 带有salt和成本因子的慢速哈希算法（BCrypt/PBKDF2/SCrypt）是强制性的，如果密码很弱，这是唯一使从哈希中检索原始密码变得困难的因素。可以在客户端执行此操作
- 服务器端哈希也是强制性的，以防止攻击者直接使用存储的哈希作为密码（如果他知道的话）。由于输入（BCrypt散列）具有足够的熵，所以散列可以在没有盐的情况下快速（SHA-256）。这样一个有60个字符的强"密码"是无法成功强制使用的
- 如果攻击者因为输入太强而无法破解快速SHA-256哈希，他可以尝试使用原始密码（来自字典）进行暴力破解。但要做到这一点，他必须首先计算慢BCrypt哈希，然后计算快SHA-256哈希
- 客户端语言，如JavaScript，通常是经过解释的，并且比编译的代码慢得多，因此您可以在与服务器相同的时间内执行更少的循环（这会削弱安全性）。如果您有可能在客户端上运行本机代码，那么在客户端执行慢速散列不会有任何缺点
不，您不应该向用户发送任何"salt"。它可以被嗅探。
您基本上要做的是发送一个可以使用一次的（csrf-）令牌。这没什么错，但你似乎在重新发明轮子。
说真的，我认为你的解决方案只适合黑客。如果我嗅到通信，我会逐渐得到用户名、salt和密码散列。您必须通过网络发送所有这些值（用户名用于获取salt，密码哈希用于验证尝试）。现在我可以在恶意登录请求中直接使用嗅探密码哈希，或者在本地开始破解密码（用户通常对更多服务使用相同的密码）。由于我不需要发送请求来猜测密码，所以对身份验证尝试的所有检查和限制都不适用。取决于哈希算法，它会或多或少地消耗时间。我认为网络嗅探是你计算不通过网络发送普通密码的主要目的。
您可以使用TLS保护您的网络通信，但在客户端上发送salt和哈希密码的所有事情都是不必要的。您只需将密码以纯文本形式发送到服务器即可。但是的，在客户端上散列密码，如果你愿意，为什么不呢。如果您认为bcrypt是性能问题，并且可能是DOS原因，那么您也可以在服务器上使用ie.sha1。
用于通过不安全网络传输信息的协议的一个很好的例子是OAuth 1.0a，即使在其中，您也需要一些密码学或TLS来传输消费者机密。
如果我理解错误，请告诉我。
我想我能看到的唯一缺点是在低端移动设备上使用它。