security - 通过 HTTP(而不是 HTTPS)对用户进行身份验证

Question

初始说明:这仅适用于个人修补项目；我不是在这里编写企业安全性，如果我是，我会比尝试编写自己的方案更好。 :-D

编辑:为了强调上述一点，我尝试将其标记为“iKnowThisWouldBeABadIdeaInRealLife”，但 SO 不会接受它，因为它超过 25 个字符。请注意，我知道它不是商业级!

我需要一种通过 HTTP 验证用户身份的方法(在这种情况下不能使用 HTTPS)。我需要知道另一端的人确实是他们所说的人(达到相当高的可信度)。一旦我确定用户是合法的，我就不会关心客户端和服务器之间的内容是否以明文形式发送。

我遇到的问题是尝试将密码从客户端发送到服务器而不以明文形式发送。我考虑过在 javascript 中尝试一些公钥加密，因为一些 Google 搜索发现了一些看起来很有趣的库。

这是我正在考虑的方案:

(假设A和A'分别代表私钥和公钥；此外，enc(text, key)和>dec(密文, key )代表加密/解密函数)

    +------------------------+------------------------------+
    |         SERVER         |            CLIENT            |
    +------------------------+------------------------------+
(1) | t = randomToken()      |                              |
(2) | enc(t, A)           -------->  c                      |
(3) |                        |       A' = getKeyFromUser()  |
(4) | p                 <--------    p=dec(c, A')           |
(5) | if (t==p)              |                              |
    |     allowAccess()      |                              |
    | else                   |                              |
    |     denyAccess()       |                              |
    +------------------------+------------------------------+

我在其中看到的一个弱点是，正在监听交换的坏人虽然没有A，但现在拥有一个已知的密文/明文组合，我从加密货币中记得这一点类是一个坏主意。我认为加盐可以以某种方式缓解这种情况？

这是我的[两个]问题:

1. 这是一个“好”计划吗？ (请记住，我不关心此初始交换之后的任何内容是否是明文 - 我只是想在这里验证初始身份)
2. 解决上述“已知明文/密文对”弱点的最佳方法是什么？腌制？

谢谢!

<小时/>

编辑:感谢您的所有讨论!只是为了澄清:

• 我并不担心向客户端保证服务器就是他们所说的那样。只有相反(向服务器保证客户端就是他们所说的人)
• 我了解 MITM 攻击。该方案并非旨在防范它们。
• 我知道已经有很多解决方案可以解决这个问题。这对我来说纯粹是一次学习练习!我并不是想重新发明轮子或 build 一个更好的捕鼠器。这只是为了好玩!

• 这是我对该方案的思考过程:(我知道我没有正确使用公钥和私钥，但请耐心等待)

  • 鲍勃走到爱丽丝面前说:“嘿，我是鲍勃。”

  • Alice 说:“好吧。我知道 Bob 的‘私钥’。如果你真的是 Bob，请拿走我刚刚(用 Bob 的私钥)加密的 secret 消息，并为我解密。”

  • Bob 回复了正确的消息，Alice 很高兴。

Answer 1

您可以使用HTTP Digest Authentication 。大多数浏览器、服务器和各种库都已经支持这一点。

编辑:

如果您确实想在没有 SSL/TLS 的情况下使用一些公钥加密技术，您可以查看 HTTPsec

如果你真的想发明自己的身份验证方案，你应该注意你的标签加密/解密错误(不确定这是一个拼写错误，或者也许我没有正确阅读图表，它看起来像你正在服务器端执行enc(t,A)):

• 您使用公钥进行加密
• 您使用私钥解密
• 您使用私钥进行签名
• 您使用公钥验证签名

在您的方案中，您需要服务器发布其公钥，并让客户端使用该公钥加密其答案，将其发送到服务器，然后服务器能够使用其私钥对其进行解密。那么困难在于确保公钥确实是合法服务器的公钥，并且没有被中间的攻击者拦截和替换:这就是 PKI 和证书与 TLS(和 HTTPS)一起发挥作用的地方。