关于我的安全层概念，哪些攻击是可能的？

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

我无论如何都不是密码或安全专家，但我确实看到了一个严重的缺陷：

客户端没有办法知道它正在运行right加密代码。对于SSL/TLS，您的浏览器供应商和服务器软件供应商都已经实现了一个公认的标准。您不需要告诉浏览器SSL是如何工作的，它是内置的，您可以相信它可以正确和安全地工作。但是，在您的情况下，浏览器只能通过从服务器接收纯文本JavaScript来了解正确的协议。

这意味着您永远不能相信客户端实际上正在运行正确的密码。除了将所有解密的消息发送到攻击者的服务器之外，任何中间人都可以提供与您通常提供的脚本行为相同的JavaScript。客户没有办法防范这一点。

这是最大的缺陷，我怀疑它是你的解决方案的致命缺陷。我看不出有什么办法能解决这个问题。只要您的系统依赖于将您的加密代码交付给客户端，您就总是容易受到中间人攻击。当然，除非您是通过SSL交付代码的:)

Answer 2

为什么每个人都必须想出他们的安全传输层？是什么让你认为你有比SSL或TLS更好的东西？我只是不明白为什么要重新发明轮子，当涉及到密码学时，这是一件特别危险的事情。HTTPS是一个复杂的野兽，它actually does a lot of work.

请记住，HTTPS还涉及身份验证(例如:能够知道您实际上是在与您认为您正在与之交谈的人交谈)，这就是为什么存在PKI和浏览器附带Root CA的原因。这是非常困难(如果不是不可能的话)并容易出现安全漏洞。回答您的问题，您如何防御MITM attacks

TLDR:别这么做。SSL/TLS工作得很好。

/endrant.

Answer 3

就“土生土长的”而言，看起来你已经做了比需要的更复杂的事情。具体地说，我认为不需要涉及非对称密钥。如果服务器已经知道用户的散列密码，那么只需让客户端生成一个会话id，并通过客户端的散列密码将其(对称地)加密到消息摘要中。

攻击者可能做的最好的事情就是嗅探初始通信量，并尝试回复attack...but，这样攻击者就无法理解服务器的响应。

请记住，如果您不使用TLS/SSL，那么您将不会获得硬件加速的加密(它将会更慢，很可能是显而易见的)。

您还应该考虑使用HMAC，只是简单地使用用户的密码作为加密密钥。