基于字符串的协议安全基础知识
我不确定如何表达这个问题，所以如果它与其他问题重复，请提前道歉。
我想彻底检查一下我如何保护基于扭曲的应用程序，并认为我在这方面做得很好，但自从我编写使用原始或托管套接字的任何内容以来，已经有十多年了。
认证交易： 客户端连接并立即发送回带有 16 个字符的十六进制字符串的质询响应。 客户端获取用户名和密码，密码转换为 sha1(salt + sha1(password))，凭据以 { username, password } 形式发送回服务器。在服务器端，身份验证执行标准查找模式（如果用户存在并且密码等于输入，则授予）。
如果用户和用户之间的连接客户端丢失，协议类将自身标记为脏并断开与用户对象的连接。此后的任何时间，要再次访问用户对象，客户端都必须使用新的盐重复身份验证过程。
我错过了什么吗？对于基于字符流的协议是否有更好/更安全的方法？
I wasn't sure how to phrase this question, so apologies in advance if it's a duplicate of something else.
I wanted to sanity check how I've secured my twisted based application and think I've done a good job at it, but it's been over a decade since I've written anything that uses raw or managed sockets.
Authentication transaction:
Client connects and immediately a challenge response is sent back with a 16 character hex string.
Client side takes user name & password, password is converted sha1( salt + sha1(password)) and credentials are sent back to the server as { username, password }. On the server side, authentication does standard lookup pattern ( if user exists and has password equal to input then grant ).
If the connection between user & client is lost, the protocol class marks itself as dirty and disconnects itself from the user object. Any time after this point, to get access to the user object again, the client would have to repeat the authentication process with a new salt.
Am I missing something? Is there a better/more secure approach for a character stream based protocol?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您描述的协议解决了一种攻击，即重放攻击。然而，您很容易受到 MITM 攻击。当攻击者进入协议时，TCP 连接不会断开。此外，通过该系统传输的任何内容都可以被嗅探。如果您在咖啡馆使用无线网络，该区域中的每个人都将能够嗅探传输的所有内容，然后对经过身份验证的会话进行中间人攻击。另一点是 sha1() 被证明是不安全的，您应该使用 sha256 来处理与安全相关的任何内容。
永远不要重新发明轮子，尤其是在安全方面。
使用 SSL！每个人都使用 SSL，并且它具有经过验证的安全性的悠久历史，但这是您无法构建的。 SSL 不仅解决了中间人攻击，而且您还可以使用证书而不是密码来验证客户端和服务器，这使您免受暴力破解的影响。在攻击者能够暴力破解 2048 位 RSA 证书之前，太阳就会燃烧殆尽。爸爸，您不必担心 eve dropper 会嗅探传输。
请记住，OpenSSL 是免费的，生成证书是免费的，证书的颁发也是免费的。尽管您想要签署证书的唯一原因是您想要实施 PKI，但这可能不是必需的。客户端可以对服务器的公钥进行硬编码以验证连接。服务器可以有一个客户端公钥数据库。该系统是独立的，不需要 OCSP 或 CRL 或公钥基础设施的任何其他部分。
The protocol you described addresses one attack, that is the a replay attack. However, you are very vulnerable to MITM attacks. The TCP connection won't drop when the attacker moves in on the protocol. Further more anything transferred over this system can be sniffed. If you are on the wireless at a cafe everyone in the area will be able to sniff everything that is transmitted and then MITM the authenticated session. Another point is that sha1() is proven to be insecure you should use sha256 for anything security related.
NEVER REINVENT THE WHEEL, especially when it comes to security.
Use SSL! Everyone uses SSL and it has a LONG history of proven secuirty, and that is something you can't build. SSL Not only solved Man in the Middle Attacks but you can also use Certificates instead of passwords to authenticate both client and server which makes you immune to brute force. The sun will burn out before an attacker can brute force a 2048bit RSA certificate. Father more you don't have to worry about an eve dropper sniffing the transmission.
Keep in mind that OpenSSL is FREE, generating certificates is FREE, and the singing of certificates is FREE. Although the only reason why you would want to sign a certificate is if you want to implement a PKI, which is probably not necessary. The client can have the server's public key hard coded to verify the connection. The server could have a database of client public keys. This system would be self contained and not require OCSP or CRL or any other part of a Public Key Infrastructure.
您的身份验证似乎很可靠，但很容易受到中间人攻击，因为它不保证与服务器连接的完整性。
我建议改为实施 SRP 6 协议。它被证明是安全的，确保连接的完整性，甚至创建一个可用于建立某种形式的对称加密的公共秘密。该协议乍一看有点困难，但实际上很容易实现。 项目网站上还有一个 JavaScript 演示，并链接到多种不同语言的实现。
Your authentication seems solid but prone to man in the middle attacks as it does not ensure the integrity of the connection to the server.
I'd suggest to implement the SRP 6 protocol instead. It is proven to be secure, ensures the integrity of the connection and even creates a common secret that can be used to establish some form symmetric encryption. The protocol looks a bit difficult at first sight but is actually quite easy to implement. There is also a JavaScript Demo available on the project website and links to several implementations in different languages.