blocks|key|941941|text|SSL/TLS提供传输层安全性，您所做的只是为了授权过程而重新做一次。您最好专注于客户端证书之类的授权技术，而不是添加额外的行级加密层。您还可以介绍许多您没有提及的内容，例如SQL+Server2008中的加密列、IPSec、layer+4&7硬件解决方案，甚至在服务器和客户端防火墙之间建立信任。我最关心的问题是，您如何创建了对用户名和密码的如此深层次的依赖，这两者在任何系统中都可以随着时间的推移而改变。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|941942|我强烈建议您重新考虑使用这种方法，并希望依靠更标准的技术来确保凭据永远不会未加密地存储在服务器上，也不会从客户端以明文形式传递。|941943|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

SSL/TLS provide transport layer security and what you've done does nothing but do that all over again for only the authorization process. You'd be better served to focus on authorization techniques like client certificates than to add an additional layer of line-level encryption. There's a number of things you could also introduce that you haven't mentioned such as encrypted columns in SQL Server 2008, IPSec, layer 4 &amp; 7 hardware solutions and even setting up trusts between the server and client firewalls. My biggest concern is how you've created such a deep dependency on the username and password, both which can change over time in any system.

I would highly recommend that you reconsider using this approach and look to rely on more standard techniques for ensuring that credentials are never stored unencrypted on the server or passed in the clear from the client.

blocks|key|941995|text|就“土生土长的”而言，看起来你已经做了比需要的更复杂的事情。具体地说，我认为不需要涉及非对称密钥。如果服务器已经知道用户的散列密码，那么只需让客户端生成一个会话id，并通过客户端的散列密码将其(对称地)加密到消息摘要中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|941996|攻击者可能做的最好的事情就是嗅探初始通信量，并尝试回复attack...but，这样攻击者就无法理解服务器的响应。|941997|请记住，如果您不使用TLS/SSL，那么您将不会获得硬件加速的加密(它将会更慢，很可能是显而易见的)。|941998|您还应该考虑使用HMAC，只是简单地使用用户的密码作为加密密钥。|941999|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

It looks like you've made more complexity than is needed, as far as "home-grown" is concerned. Specifically, I see no need to involve assymetric keys. If the server already knows the user's hashed password, then just have the client generate a session id rolled into a message digest (symmetrically) encrypted via the client's hashed password. 

The best an attacker might do is sniff that initial traffic, and attempt a reply attack...but the attacker would not understand the server's response.

Keep in mind, if you don't use TLS/SSL, then you won't get hardware-accelerated encryption (it will be slower, probably noticeably so).

You should also consider using HMAC, with the twist of simply using the user's password as the crypto key.

blocks|key|942058|text|虽然我也主张在这类事情上使用SSL/TLS，但重新发明轮子并没有错；它会带来创新，比如堆栈交换系列网站。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|942059|我认为你的安全模型已经足够了，而且相当智能，尽管你在客户端使用的是什么？我假设是javascript，因为你给这篇文章加上了“web-development”的标签？或者，您是否正在使用它与某种插件进行通信？您的实现产生了多少开销？|942060|一些值得关注的领域：|942061|-How您是否正在处理初始通信，例如:用户登录、注册？|942062|关于中间人攻击的-What+(向客户端保证它正在与授权的服务器对话)？|942063|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

While I would also advocate the use of SSL/TLS for this sort of thing, there is nothing wrong with going re-inventing the wheel; it leads to innovation, such as the stack exchange series of websites.

I think your security model is quite sufficient and rather intelligent, although what are you using on the client-side? I'm assuming javascript since you tagged this post with 'web-development'? Or are you using this to communicate with a plug-in of sorts? How much overhead does your implementation produce?

Some areas of concern:

-How are you handling initial communication, such as: user login, registration?

-What about man-in-the-middle attacks (assuring the client that it is talking to the authorized server)?

blocks|key|1156227|text|您的主要问题是您的客户端加密代码是通过未经验证的HTTP以Javascript的形式提供的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1156228|这给中间人提供了大量的选择。他可以修改代码，使其仍然可以通过您的服务器进行身份验证，但也可以将对话的密码/私钥/明文发送给他。|1156229|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The major problem you have is that your client crypto code is delivered as Javascript over unauthenticated HTTP.

This gives the Man-In-The-Middle plenty of options. He can modify the code so that it still authenticates with your server, but also sends the password / private key / plaintext of the conversation to him.

blocks|key|942146|text|当你的对手是一个可以看到你的流量但不能修改它的窃听者时，Javascript加密就足够了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|942147|请注意，我指的不是您的具体想法(我没有花时间完全理解它)，而是指Javascript加密的一般概念。|942148|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Javascript encryption can be enough when your adversary is an eavesdropper that can see your traffic but not modify it.

Please note that I am not referring to your specific idea (which I did not take the time to fully understand) but to the general concept of Javascript encryption.

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:

<pre><code>User registers -&gt; 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 -&gt; authenticates with nickname+password hash
(normal nick/password -&gt; 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

---&gt; From this point on the whole traffic gets AES-encrypted
 using that Session Password
</code></pre>

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?

Which attacks are possible concerning my security layer concept?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

尽管所有人都建议使用SSL/https/等，但我还是决定在http之上为我的应用程序实现自己的安全层……该概念的工作原理如下：User registers -> a new RSA Keypair is generatedthe Private Key gets encrypted with AES using the...

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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