问题描述
尽管有使用 SSL/https/etc 的所有建议.我决定在 http 之上为我的应用程序实现我自己的安全层......这个概念的工作原理如下:
Despite all the advices to use SSL/https/etc. I decided to implement my own security layer on top of http for my application... The concept works as follows:
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 标头包含敏感信息的可能性)...但我有偏见，所以我问 - 我的安全实施是否提供足够的......安全性?
I found no hole in that chain - neither the private key nor the login password get ever sent to the server as plaintext (I make no use of cookies, to exclude the possibility of the HTTP Cookie header to contain sensitive information)... but I am biased, so I ask - does my security implementation provide enough... security?
推荐答案
无论如何我都不是加密或安全专家，但我确实看到了一个严重的缺陷:
I'm not a crypto or security expert by any means, but I do see one serious flaw:
客户端无法知道它正在运行正确加密代码.使用 SSL/TLS，您的浏览器供应商和服务器软件供应商都已经实施了一个商定的标准.您无需告诉浏览器 SSL 是如何工作的，它是内置的，您可以相信它可以正确且安全地工作.但是，在您的情况下，浏览器只能通过从您的服务器接收纯文本 JavaScript 来了解正确的协议.
There is no way the client can know that it is running the right crypto code. With SSL/TLS there is an agreed upon standard that both your browser vendor and the server software vendor have implemented. You do not need to tell the browser how SSL works, it comes built in, and you can trust that it works correctly and safely. But, in your case, the browser only learns about the correct protocol by receiving plain-text JavaScript from your server.
这意味着您永远无法相信客户端实际上正在运行正确的加密代码.任何中间人都可以传递行为与您通常提供的脚本相同的 JavaScript，除了它将所有解密的消息发送到攻击者的服务器.并且客户端无法防止这种情况发生.
This means that you can never trust that the client is actually running the correct crypto code. Any man-in-the-middle could deliver JavaScript that behaves identically to the script you normally serve, except that it sends all the decrypted messages to the attacker's servers. And there's no way for the client to protect against this.
这是最大的缺陷，我怀疑这是您的解决方案的致命缺陷.我没有办法解决这个问题.只要您的系统依赖于将您的加密代码交付给客户端，您就总是容易受到中间人攻击.当然，除非您通过 SSL 交付该代码 :)
That's the biggest flaw, and I suspect it's a fatal flaw for your solution. I don't see a way around this. As long as your system relies on delivering your crypto code to the client, you'll always be susceptible to man-in-the-middle attacks. Unless, of course, you delivered that code over SSL :)
这篇关于哪些攻击可能与我的安全层概念有关?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！