Question

尽管有使用SSL / https /等的所有建议。我决定在我的应用程序的http顶部实现我自己的安全层...这个概念的工作原理如下：

User registers -> a new RSA Keypair is generated
the Private Key gets encrypted with AES using the users login Password
(which the server doesnt know - it has only the sha256 for authentication...)

Server stores the hash of the users password
 and the Encrypted Private Key and Public Key

User logs in -> authenticates with nickname+password hash
(normal nick/password -> IP-bound sessionid authentication)
Server replies: sessionid, the Encrypted RSA Private Key
    and an Encrypted randomly generated Session Communication Password

Client decrypts the RSA Private Key with the users Password
Client decrypts the Session Communication Password with the RSA Private Key

---> From this point on the whole traffic gets AES-encrypted
     using that Session Password

我发现该链中没有漏洞 - 私钥和登录密码都不会以明文形式发送到服务器（我不使用cookie，以排除HTTP Cookie标头包含敏感信息的可能性）。 ..但我有偏见，所以我问 - 我的安全实施是否提供了足够的......安全性？

Answer 1

为什么所有人必须提出他们的安全传输层？是什么让你认为你有比SSL或TLS更好的东西？我根本不理解重新发明轮子的动机，这在加密方面是一件特别危险的事情。 HTTPS是一个复杂的野兽，它是actually does a lot of work.

请记住，HTTPS还涉及身份验证（例如：能够知道您实际上正在与您认为正在与之交谈的人进行交谈），这就是为什么存在PKI并且浏览器随Root CA一起提供的原因。这很难（如果不是不可能的话）重新发明并且容易出现安全漏洞。要回答你的问题，你如何防御MITM attacks？

TLDR：不要这样做。 SSL / TLS工作正常。

/endrant.

Answer 2

我不是一个加密或安全专家，但我确实看到了一个严重的缺陷：

客户端无法知道它正在运行正确加密代码。使用SSL / TLS，您的浏览器供应商和服务器软件供应商都已达成一致的标准。您不需要告诉浏览器SSL是如何工作的，它是内置的，您可以相信它可以正常且安全地工作。但是，在您的情况下，浏览器只通过从您的服务器接收纯文本JavaScript来了解正确的协议。

这意味着您永远不会相信客户端实际上正在运行正确的加密代码。任何中间人都可以提供与您通常服务的脚本相同的JavaScript，除了它将所有解密的消息发送到攻击者的服务器。并且客户无法防范这种情况。

这是最大的缺陷，我怀疑这对你的解决方案来说是一个致命的缺陷。我没有看到解决这个问题的方法。只要您的系统依赖于向客户端提供加密代码，您将始终容易受到中间人攻击。当然，除非您通过SSL提供该代码：）

Answer 3

就“本土化”而言，看起来你的复杂程度超出了所需要的程度。具体来说，我认为没有必要涉及不对称的密钥。如果服务器已经知道用户的哈希密码，那么只需让客户端通过客户端的哈希密码生成会话ID，该会话ID被转换为消息摘要（对称）加密。

攻击者可能做的最好的事情是嗅探初始流量，然后尝试回复攻击......但是攻击者无法理解服务器的响应。

请记住，如果您不使用TLS / SSL，那么您将无法获得硬件加速加密（它会更慢，可能会更加明显）。

您还应该考虑使用HMAC，只需使用用户密码作为加密密钥。

Answer 4

SSL / TLS提供传输层安全性，您所做的只会对授权过程重复执行此操作。您可以更好地专注于客户端证书等授权技术，而不是添加额外的行级加密层。您还可以介绍一些您未提及的内容，例如SQL Server 2008，IPSec，第4层和第4层中的加密列。 7个硬件解决方案，甚至在服务器和客户端防火墙之间建立信任。我最关心的是你如何对用户名和密码产生如此深刻的依赖，这两者都会随着时间的推移在任何系统中发生变化。

我强烈建议您重新考虑使用此方法，并希望依靠更多标准技术来确保凭据永远不会在服务器上以未加密方式存储或从客户端以明文形式传递。

Answer 5

虽然我也提倡使用SSL / TLS进行此类操作，但重新发明轮子并没有错;它带来了创新，例如堆栈交换系列网站。

我认为您的安全模型非常充足且非常智能，尽管您在客户端使用的是什么？我假设javascript，因为你用'web-development'标记了这篇文章？或者您是否使用此插件与各种插件进行通信？您的实现会产生多少开销？

一些值得关注的领域：

- 您如何处理初始通信，例如：用户登录，注册？

- 关于中间人攻击（确保客户端正在与授权服务器通信）？

Answer 6

您遇到的主要问题是您的客户端加密代码是通过未经身份验证的HTTP以Javascript格式提供的。

这为Man-In-The-Middle提供了充足的选择。他可以修改代码，使其仍然可以通过服务器进行身份验证，还可以将密码/私钥/明文发送给他。

Answer 7

当你的对手是一个可以看到你的流量而不是修改它的窃听者时，Javascript加密就足够了。

请注意，我并非指的是您的具体想法（我没有花时间完全理解），而是指Javascript加密的一般概念。

哪些攻击可能与我的安全层概念有关？

7 个答案:

TLDR：不要这样做。 SSL / TLS工作正常。