是否可以在 ac#asp.net 站点的查询字符串中安全地包含密码。
我知道的一些假设和事情 -
我知道该站点可能容易受到跨站点脚本和重放攻击。我该如何减轻这些？
鉴于上述情况，我应该如何在查询字符串中包含密码？
请不要问我“为什么”，我知道这不是一个好主意，但这是客户想要的。
您可以使用 SSL 连接安全地将密码发送到 Web 服务器。这会加密客户端/服务器之间的所有通信。
基本身份验证协议将用户/密码信息放在 HTTP 请求标头中。C# 和许多其他 Web 服务器语言可以访问此信息，并使用它来验证请求。当与 SSL 混合时，这是非常安全的。
如果以上都不可行，那么建议您为每个用户创建一个唯一的密钥。而不是发送他们的密码，这个密钥被使用。优点是密钥存储在数据库中，可以删除。用户的密码保持不变，但他们必须重新注册才能获得新密钥。如果有人可能滥用他们的密钥，这很好。
握手是客户端向服务器发出请求，服务器发回随机生成的密钥。然后，客户端使用密钥从该密钥生成哈希，并将其发送回服务器。然后服务器可以检查客户端是否知道正确的秘密。如果密码是秘密并且客户端在请求中包含用户名详细信息，则可以执行相同的操作。这可以在不发送密码的情况下进行身份验证。
如果以上都不是可能的选项，那么您可以尝试使用 JavaScript 在密码通过开放 URL 发送之前对其进行加密。我找到了AES 分组密码的开源版本。该项目名为JSAES，支持 128 到 256 位加密。可能还有其他 JS 库做同样的事情。
通常不建议将秘密放在查询字符串中，然后可以将其标记和复制，从而将静态密码暴露在历史文件、cookie 等中。
为了在这个用例中保护密码，一个选项是散列密码（单向，不可逆）。通过这种方式，实际密码在传输过程中或静止状态下都是未知的，但是......这意味着攻击者仍然可以使用散列值登录服务器，该服务器可能会将散列值与其存储进行比较以进行身份验证。
更新：切换到无状态 (JWT) 会话
在过去，越野车是一件事（好吧-它们仍然是一些边缘群体的事情，但是）-我们使用“会话”。例如，在基于 Java/J2EE/Servlet 的系统中，“会话 ID”（参见 JSESSION_ID）被存储为 cookie。该值是一个随机数，很难猜测 - 但它存在从劫持到内存和服务器上查找开销的问题。
在 2020 年（截至撰写本文时）... JSON Web 令牌 (JWT) 可用于安全地封装用户会话信息，并在不暴露密码的情况下将其推送回不可变的 cookie，并且服务器开销很小。
在此模型中，登录后，服务器会发出一个令牌（使用 OAUTH2 或相关），该令牌具有过期时间戳。
然后可以对这些数据和可能的其他会话信息进行加密、散列、签名和包装在 JWT（令牌）中 - 作为返回 Web 浏览器的 cookie。
在这一点上，客户端不能做任何事情来破坏（甚至查看）cookie，因为任何敏感数据都应该被加密（使用 AES256 等或更好）并且内容被散列和散列签名。这意味着当服务器取回令牌时，它会查看时间戳并可能将其丢弃 - 强制重新身份验证，然后......
否则可以验证它对内容进行签名，对内容进行哈希处理，并在需要时验证哈希和解密数据（其中不包括密码，而只是用户的 ID - 已验证且本身不一定是秘密）。
这可以包括用户可以执行的操作的已查找范围（授权）等 - 在令牌超时之前避免往返身份验证服务器。
因此，上述方法（使用 JWT、散列、签名、加密 - 到 cookie 中）是推荐的方式，既可以实现无状态，又可以避免在客户端和服务器之间传递秘密。
参考：https ://auth0.com/blog/stateless-auth-for-stateful-minds/
此外，考虑到多因素身份验证方案（请参阅 Google 身份验证器）和相关系统的安全性要强得多（窃取密码是不够的，并且密钥会在外部系统上自动轮换），但确实需要对轮换密钥的半频繁访问系统，在一定程度上抑制了流畅的用户体验。
更新：Google 和其他人的 Multi-Factor auth 已经变得更好了。
老公司仍然使用 SMS 一次性密码 (OTP) ... 可以通过前往无线公司商店并声称 SIM 卡丢失（给定一个已知的电话号码）来破坏它。谷歌和其他更先进的公司相对使用可嵌入智能手机应用程序中的旋转令牌，然后用于许多服务。谷歌甚至有推送通知，用户只需按下按钮确认：“是的 - 是我”。