Security ASP经典用户登录系统密码安全注意事项？

全部,

我目前正在用ASP classic设计一个用户帐户系统……不要评判，这是我所熟悉的；）。我已经构建了几个组件，包括UI、数据库表、CRUD数据库ASP页面和通用邮件程序。我很想知道为ASP实现安全登录系统的一些最佳实践。搜索web会产生大量我以前使用过的“简单ASP安全”解决方案，但这是我第一次构建一个健壮且真正安全的解决方案。最终的实现将用于工作申请系统，因此，由于内容的原因，它肯定需要安全

到目前为止，我已经：

• 密码恢复/重置仅适用于文件中的电子邮件帐户
• 散列数据库中存储的密码
• 不要在会话cookie上设置过期时间，这样它们只会存储在内存中（今天在某个地方阅读）
• 获取服务器的证书并使用https

我有几个一般性的问题

在表单中提交密码将通过查询字符串传递密码。我是否需要在提交表单之前对此进行哈希处理

另一方面。。。如果我使用的是https，因为它已经是安全的，我可以在ASP页面上进行哈希处理，以处理对数据库的写入吗？我正在使用AJAX解析发送表单中的查询字符串，并将其传递到ASP页面，该页面连接到数据库并执行CRUD操作

密码恢复/重置仅适用于文件中的电子邮件帐户

确保您的发送重置链接在特定时间后或使用后过期，以先到者为准

散列数据库中存储的密码

使用盐而不是简单的散列。大多数常见密码的哈希值都很容易破解

不要在会话cookie上设置过期时间，以便它们只存储在 记忆（今天在某处读）

这将确保在用户关闭浏览器时清除cookie。除此之外，还考虑服务器端会话cookie的超时，这将在不活动的X分钟后超时用户会话。p> 获取服务器的证书并使用https

至少，登录凭据绝对需要通过SSL传递。它还将有助于将整个网站置于https上，而不仅仅是登录页面。SSL不再是一种安全协议。将整个站点置于SSL上可以防止任何错误。确保您的服务器不支持SSLv3以防止最近的攻击

在表单中提交密码将通过查询字符串传递密码。 我是否需要在提交表单之前对此进行哈希处理

请不要通过querystring传递凭据。登录表单应始终张贴。如果将它作为查询字符串附加到URL，它将缓存在服务器日志（以及任何代理日志）中

如果您是通过https发布表单（您绝对应该这样做），则在提交表单之前无需散列。如果您未使用https，则无法将凭据安全地传递到服务器

另一方面。。。如果我使用https，因为它已经是安全的， 我可以在ASP页面上进行哈希处理，以处理对 数据库我正在使用AJAX解析来自发送端的查询字符串 窗体并将其传递到连接到数据库和 执行CRUD操作

---

哈希应该始终在服务器端完成。如果在客户端对密码进行散列并通过http以明文形式发送，则MITM可能无法从散列中反转密码，但他可以始终使用相同的散列登录到用户的帐户。在这种情况下，散列实际上变成了用户的纯文本密码。

请务必将HTTP POST与SSL一起使用

保护asp代码不受sql注入的影响

存储带有加密令牌的本地cookie，以便用户在关闭会话/浏览器后保持登录，或者使用asp会话进行单一登录，该登录可能在上次请求后20分钟内或关闭浏览器时过期

保护您的cookie以防cookie/会话劫持。（）

---

此外，您可以通过请求/存储/验证服务器变量（如用户代理的一部分）来使用用户的指纹。

我只想添加一个指向此SO帖子的链接，以详细说明为什么不通过querystring传递密码。好建议，好答案+这是一个很好的建议。谢谢我对总是发布登录信息（没有AJAX）这一部分特别感兴趣。我不知道，我相信这会帮我省去很多麻烦！关于做盐，你能推荐什么好的ASP功能？我还将密码发送回一个管理员可见的用户表，所以我想只要我使用https，在发送回密码之前，我就可以在服务器端使用https了？我目前正在使用我正在使用的“不安全”版本的AJAX来完成这项工作。因为它只是一个div中的纯文本，我想这仍然可以吗？很抱歉问了这么多问题！散列是一个单向的过程，所以没有什么比脱盐更好的了。salt散列的工作方式是，获取密码，向其中添加随机字符串（salt），然后对其进行散列（查找ASP的SHA1实现）。注意，您将在数据库中存储哈希和salt。接下来，当您必须验证用户提供的密码时，您对用户密码执行相同的操作，即从数据库中获取salt，将其附加到用户提供的密码并对其进行散列。如果生成的哈希值与数据库中的哈希值匹配，则密码是正确的，您允许用户进入。