我真的只是想从安全角度看下面的建议有多愚蠢。
我有两个网站。一个是管理门户，另一个是成员门户。
在管理门户中，管理员可以检索成员列表，我需要为管理员提供登录成员门户的能力，而无需输入成员登录凭据。
两者都是IIS中的单独网站，对于这种讨论，可以说它们位于不同的服务器上。
两个网站都访问相同的SQL Server数据库。
我想我可以在管理员点击“以会员身份登录”链接创建一个随机代码字符串，并将其与会员编号一起保存到数据库中。
然后，我可以将代码和成员编号作为查询字符串参数传递给成员门户网站。
然后，成员门户读入这些值并在数据库中检查它们以验证代码字符串是否存在，如果是，则它与正在传递的成员编号匹配。然后，我可以登录该成员并在数据库中设置一个标志，将代码设置为正在使用，因此对将来的请求无效。
我正在考虑绕过这个黑客需要成功猜出随机代码并将其传递给该页面以及该代码的相应成员编号，并将该组合标记为在数据库中未使用。
考虑到在生成的代码和正在使用的代码之间只传递秒数，这似乎不太可能。
如果有必要，我可以随时检查请求的IP地址，因为管理门户的用户都共享相同的固定IP地址。
那么您认为上述内容是否会经得起安全审查的审查，还是需要沿着SSO路线进行审核？
答案 0 :(得分：2)
假设为管理员使用HTTPS以及适当的物理和IT安全流程和程序，这种方法应该足够了。它比大多数金融网站密码重置更安全，通常只需要受到破坏的电子邮件帐户和一些个人信息来重置密码。如果您同时检查原始客户端请求的IP地址范围，则黑客必须已经可以访问您的系统或网络。此外，如果您将代码设为GUID，那么（实际上）人们无法猜测。
您可以通过在每次发生此事件时将记录存储在数据库中来添加一层检查黑客尝试（或者至少每次由于错误的密钥而失败），并且每次发生时都要运行检查以查看是否它经常发生（比如过去一小时的100次，或者其他什么 - 正确的数字取决于你预期它发生的频率）。如果它发生得太频繁，那么让它向IT人员发送警报并恢复，以便用户必须手动输入他们的凭据。
免责声明：我不是任何安全专家，所以我很乐意推迟任何声称拥有此类身份的人。由于缺乏答案，我在这里称重。
答案 1 :(得分：2)
你的方法非常合理。我可以证实，因为我出于这样的原因实施了这样的解决方案。我们分析了选项和曝光度。实施后，我们的应用程序通过了 PCI Complaince Audit 。
<强>理由：
SSL是必不可少的！可以防止嗅探器。必要。如果没有加密，嗅探器可以检测到您的GUID，并且可能有一个窗口可以使用它。）
正如Tony指出的那样， GUID实际上是不可行的。
<强>建议：
AntiForgery令牌是一个cookie，用 __ RequestVerificationToken 填充你的HTTPHeaders，这几乎和你的GUID一样难以猜测。
已建立的框架负担加密密码的负担。 MS框架（如 简单成员 和 身份 ）集成到现代ASP.NET框架中，为您提供强大的功能基础依靠。
如果您使用的是旧版框架，如经典ASP或.NET 2.0，则classic Membership Provider更合适。
如果您使用 实体框架 创建新的 MVC 5 应用程序，我强烈建议您使用 身份2.1 。