HttpContext.Current.User.Identity.Name 是如何工作的？它有多安全？答案

【问题标题】：How does HttpContext.Current.User.Identity.Name work? and how secure is it?HttpContext.Current.User.Identity.Name 是如何工作的？它有多安全？
【发布时间】：2012-11-16 10:07:21
【问题描述】：

我正在使用 HttpContext.Current.User.Identity.Name 来获取登录用户的用户名。我想知道这是如何工作的（使用 NTLM v2 / Kerberos）以及它的安全性如何？用户可以尝试模仿他是其他人吗？

基本上，从安全的角度来看，有什么我应该担心的，或者我应该如何改进它？

【问题讨论】：

您绝对可以放心！一旦用户通过身份验证（并且它是可能存在安全问题的地方），那么该属性就可以完全安全地使用。您可以改进/选择的是身份验证方法、密码强度、http（非-s）嗅探和类似的东西。
@Adriano - 我的应用程序正在使用 HTTPS。身份验证方法仅在 Windows 登录时完成，而不是与应用程序有关，这是正确的吗？有没有关于这个问题的微软参考资料？
您使用 Windows 身份验证吗？那么它应该足够安全（并且薄弱的部分是Windows用户用于登录的密码）。根本不用担心 User.Identity，它是安全的。安全问题更容易来自我们编写的代码（以及用户将选择的密码），而不是来自“基础设施”和经过良好测试的代码。
@Adriano - 'HttpContext.Current.User.Identity.Name' 是集成 Windows 身份验证的示例吗？因为这就是我在应用程序上用于 Windows 身份验证的内容。从 Active Directory 身份验证的角度来看，我们应该使用它，是的！
用户是谁以及他们如何进行身份验证是两个独立的问题 ntlm x.509 证书和 Web 表单是识别和身份验证过程的一部分身份验证成功完成后系统会报告当前用户身份。使用至少 1024 位的 https 和 ssl 证书保护协议，以防止流量嗅探，域内连接的 ntlm 将是安全的

标签： c# asp.net security iis

【解决方案1】：

如果您使用 Windows 身份验证进行身份验证（鉴于您提到 NTLM/Kerberos，您似乎就是这样），那么会发生什么（大致）如下

IE 向您的 Web 服务器发送一个没有身份验证标头的请求。
IIS 使用 401 响应代码拒绝该请求，并告诉浏览器它想要的身份验证方案（在本例中为 Negotiate，它首先尝试 Kerberos，然后回退到 NTLM）
遏制握手发生在多个连接上，票证已根据 AD 进行验证
IIS 将票证向下传递给 ASP.NET，ASP.NET 在构建请求对象的过程中使用票证中的身份详细信息填充分配给请求的线程上的主体。
当您访问 HttpContext.User 时，您会看到当前线程的主体。

这是安全的。它与通过文件共享或其他任何使用 kerberos 的方式连接到 Windows 服务器时使用的身份验证类型基本相同。绝大多数工作实际上是 IIS 和 Windows 本身完成的，ASP.NET 只是为您提供了一种查询结果的好方法。

【讨论】：

使用表单身份验证时，User.Identity.Name 是否同样安全？
你提到的这张“票”是什么？用户欺骗这张票有多容易？