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

Question

我正在使用HttpContext.Current.User.Identity.Name来获取已登录用户的用户名。我想知道它是如何工作的（使用NTLM v2 / Kerberos），以及它有多安全？用户是否可以尝试模仿成别人？

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

- Ryan S

---

你使用Windows身份验证吗？好吧，它应该足够安全（弱点是Windows用户登录时使用的密码）。完全不用担心User.Identity，它很安全。安全问题更容易来自我们编写的代码（和用户选择的密码），而不是“基础设施”和经过充分测试的代码。 - Adriano Repetti

@Adriano - “HttpContext.Current.User.Identity.Name” 是集成Windows身份验证的一个例子吗？因为这是我在应用程序上使用的Windows身份验证方式。从Active Directory身份验证的角度来看，我们应该使用它，对吗！ - Ryan S

不，无论您使用何种身份验证方式，HttpContext.Current.User.Identity.Name始终是那样的。 - Adriano Repetti

用户身份和认证方式是两个不同的问题，NTLM、X.509证书和Web表单是身份验证过程的一部分。成功完成认证后，系统会报告当前用户身份。使用HTTPS和至少1024位的SSL证书来保护协议，以防止流量被嗅探。在域内连接中使用NTLM可以确保安全性。 - Mike Beeler

深入的链接，有丰富的细节：http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication - Seafish

Answer 1

如果您正在使用Windows身份验证进行身份验证（根据您提到的NTLM / Kerberos，似乎是这样），那么大致的过程如下：

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

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

- blowdart

---

在使用表单身份验证时，User.Identity.Name是否同样安全？ - Brad Bamford

你提到的“ticket”是什么？用户伪造这个“ticket”有多容易？ - Seafish