我正在尝试为用户创建一种安全的方式，以便在我的自定义网站上登录并执行某些授权操作。我试图在不使用SSL的情况下获得良好的安全性。 现在登录，这是我想要改进的地方：
这个想法是，如果有人设法提取这样的cookie（或初始请求），则无法获得用户的密码。
这很棒，而且还有重复攻击和中间人攻击的问题，当“坏人”和“坏人”发生冲突时。提取请求，并使用令牌代表其他用户执行操作。
通过阅读如何防止这种情况发生，我发现一种可接受的防止这种情况的方法可能是添加一个计数器＆＃39;到cookie中的标记，以显示令牌被使用了多少次。
我们假设cookie最初包含一个令牌和一个0的计数器，如cookie-content: "abc123:0"，其中令牌为abc123，计数器为0。它建议客户端在每次发出请求时递增计数器。假设用户想要向另一个用户发送聊天消息。然后，附加到此请求的Cookie将包含"abc123:1"。后端存储计数器和令牌，并检查两个值。如果收到的计数器超过了存储的计数器，真棒。如果一个坏人＆＃39;接收请求并尝试重复它，计数器仍然是1，服务器将拒绝它，因为存储的计数器也是1（或更多）。
这听起来不错，但我不确定这更安全吗？这个坏人＆＃39;可以简单地将cookie中的计数器值编辑为99999并成功吗？
我认为cookie的内容（令牌和计数器）应该以某种方式进行哈希处理，以使内容不是纯文本。但是，客户端是HTML / JavaScript;这个坏人＆＃39;可以简单地检查使用哪种加密方法，并解密它。所有脚本都是公开的。
我通过发送一次性秘密＆＃39;在提出请求之前从服务器到客户端，但我不知道如何实现这一点。我想，在请求www.example.com/chat时，我可以生成一个随机的秘密＆＃39;并将其发送给客户端，客户端可以在发送聊天消息时将其添加到cookie中，或者将其用作密钥，以便加密更安全，但服务器在收到请求后如何知道秘密？服务器如何逆转这个？服务器在解密时必须知道密码，那么应该在哪里存储？哈希旁边的cookie中的纯文本？那个坏人＆＃39;可以做同样的事情。在数据库中？在请求www.example.com/chat时，后端是否应该知道WHO正在请求它，以便它可以与该用户一起存储在数据库中？在这种情况下，后端如何验证用户，以确保不是中间人或重复攻击请求/聊天？
这种安全方法叫做什么，是否可以将它用于我需要的（使用HTML / JavaScript）？如果没有，除SSL之外，我有哪些选择？
答案 0 :(得分：0)
它被称为不良安全，不依赖于信任。
客户端需要完全信任服务器，否则所有内容（包括用于输入密码的页面）都不可信任。目前，建立信任的唯一方法是在浏览器中提供的证书存储（您应能够信任浏览器！）。唯一能够在浏览器中使用它的软件是SSL / TLS。