数据传输和密码加密方案 [英] A proposal for Data Transmission and Password Encryption

问题描述

假设相互信任的第三方不可用，我需要实施免费的方案（无SSL证书），可以满足敏感数据传输，保护和存储的要求，也就是我们不能使用SSL，TLS但这并不意味着我将自己实施SSL，我仍然希望将加密和解密部分外包给现有代码。

我已经在下面的草案中草拟我的帐户和密码保护解决方案：

对我们的攻击者的假设：

1. 具有协议的完整知识。




2. 可以访问常用密码的大型字典。

   / li>
   

3. 可以窃听客户端和服务器之间的所有通信。




4. 可以拦截，修改和伪造任意消息在客户端和服务器之间。




5. 可以访问客户端的源代码（包括加密代码）。

解决方案：

• RSA（加密&在客户端和服务器站点分别进行解密，公钥对于传输是安全的，如果密钥是由黑客获得的，则不存在风险。）




• SHA256 / SHA512 /两次MD5（加密用户ID绑定Salt，都存储在服务器站点的数据库中）我在这里使用绑定盐避免常见的密码，并防止彩虹表。）

注册新用户

1. 在服务器端生成RSA密钥（存储在会话中）;




2. 将公钥发送给客户端




3. 将公钥存储在javascript变量中;




4. 在所有后续请求中，使用此密钥加密数据并发送到服务器;

   li>
   

5. 使用存储在会话中的私钥在服务器端解密用户帐户和密码;




6. 加密密码具有随机盐的单向加密算法（如通用意见：SHA-256比MD5更强）;




7. 将用户ID，哈希密码和随机盐（用户ID绑定）存储到数据库中（避免常见的密码和建立特定的彩虹表）。

现有用户登录

1. 首先在服务器端生成RSA密钥（存储在会话中）;




2. 将公钥发送给客户端




3. 将公钥存储在JavaScript变量中;




4. 在所有后续请求中，使用此密钥加密数据并发送到服务器;




5. 使用存储在会话中的私钥在服务器端解密用户帐户和密码;




6. 哈希密码和使用用户帐户的数据库中的盐;




7. 使用获得的随机盐加密密码，单向加密算法;




8. 将加密的密码与从数据库获取的哈希密码进行比较;




9. 确定登录成功或失败。

我在这部分是新的，我需要一些专业的建议吗？该计划是否足够安全？非常感谢。

解决方案

这里的主要问题是您正在做很多工作，而您没有得到任何更好的安全性，而不是一个自签名的SSL证书，你将自己设定为负责任的一方来关闭任何可能的漏洞并维护系统的安全性（提示：这是一个大交易）。

所以，如果你正在谈论一个普遍可用的Web应用程序，你希望用户能够使用，并有安全的信心使用，那么支付一个签名的SSL证书就是你唯一的选项。也就是说，一对夫妇注意到：

1. 你提到的哈希值可以，但是如果你想要真正的安全性使用像pbkdf2（google这个和你的眼睛将被打开到真正安全的深度和难度）


2. 没有验证服务器的身份（登录签名的SSL证书的目的），你打开自己中间人的袭击。如果其他人可以冒充您，并具有拦截，修改和伪造客户端和服务器之间的任意消息的全部功能，那么他们很容易从用户那里对他们想要的任何信息进行网络钓鱼。所以，如果您打算这样做是一个完整的解决方案，那么您需要解决这个问题。

编辑：阅读后想更多地了解你正在寻找什么，我想我可能会为您提供一个解决方案。

真的有两件事你想要保护：你的内容和您的用户凭据。你确定你的内容不值得每年花费35美元来确保，这是公平的，完全合理的。您仍然希望为您的用户的凭据提供尽可能多的安全性，因为该信息对他们和那些可以利用它们的用户来说是有价值的。

不想花钱来保护您的内容，您仍然希望只有凭证用户可以访问这些内容。所以，而不是让用户创建用户名/密码，这将是值得保护的，只需让他们用他们的电子邮件地址登录。

您的内容和电子邮件地址是第三方可以获得足够的技能和动力，但从您所说的内容中，您的内容可能不值得付出努力，他们的电子邮件地址并不那么敏感。但是您仍然可以在世界和您的内容之间建立登录网关，您可以利用双重选择限制垃圾邮件等。您可以轻松扩展此类系统以包含用户名/密码，并使用SSL（如果您的内容）成长需要它。

I need to implement a free of charge scheme (no SSL certificate) which can meet the requirements on the sensitive data transmission, protection and storage, assuming mutually trusted third party is not available, that is, we cannot use SSL, TLS etc. But this doesn't means I will implement SSL by myself, I still would like to outsourcing encryption and decryption parts to existing codes.

I have drafted below scheme as my account and password protection solution:

Assumptions on our attackers:

1. have complete knowledge of the protocol.

2. have access to a large dictionary of commonly used passwords.

3. can eavesdrop on all communications between client and server.

4. can intercept, modify, and forge arbitrary messages between client and server.

5. can access the source codes (including encryption code) on the client-side.

Solutions:

• RSA (encryption & decryption on client and server sites respectively, public key is safe for transmission, there are not risk if the key is obtained by a hacker.)

• SHA256/SHA512/Twice MD5 (Encryption with User ID binding Salt, both stored in database on the server site. I use binding salt here to avoid common password and prevent rainbow table.)

Registering a New User:

1. First Generate RSA keys on server end ( Stored in session);

2. Send public key to client;

3. Store public keys in javascript variable;

4. In All subsequent requests use this key to encrypt data and send to server;

5. Use private keys stored in session to decrypt user account and password on server side;

6. Encrypt the passwords with one-way encryption algorithm with a random salt (like the common opinion： SHA-256 is stronger than MD5);

7. Store the user id , the hash password and the random salt (user id binding) into database ( avoid common password and building specific rainbow table).

Existing User Login:

1. First Generate RSA keys on server end (stored in session);

2. Send public key to client;

3. Store public keys in javascript variable;

4. In All subsequent requests use this key to encrypt data and send to server;

5. Use private keys stored in session to decrypt user account and password on server side;

6. Fetch the hash password and the salt from database by using the user account;

7. Encrypt the passwords with one-way encryption algorithm with the obtained random salt;

8. Compare the encrypted password with the hash password obtained from the database;

9. Determine login success or failure.

I am new in this parts and I do need some professional suggestions from you? Is the scheme secure enough? Many thanks.

解决方案

The main problem here is that you're doing a whole lot of work and you're not getting any better security than a self-signed SSL certificate, and you set yourself up as being the responsible party to close any possible holes and maintain the security of your system (hint: this is a Big Deal).

So, if you're talking about a generally available web application that you want your users to be able to just use, and use with confidence of security, then paying for a signed SSL certificate is really your only option. That said, a couple notes:

1. The hashes you've mentioned are OK, but if you want real security use something like pbkdf2 (google this and your eyes will be opened to the depth and difficulty of real security)
2. Without verifying the identity of the server (the purpose of signing in a signed SSL certificate) you open yourself up to man-in-the-middle attacks. If someone else can impersonate you, and has the full ability to "intercept, modify, and forge arbitrary messages between client and server", then it's simple for them to phish whatever info they want from your users. So, that's a problem you'll need to address if you intend for this to be a complete solution.

Edit: After reading and thinking more about what you're looking for, I think I may have a solution for you.

There's really two things that you could want to secure: your content, and your users credentials. You've determined that your content isn't worth spending $35 a year to secure, which is fair enough and perfectly reasonable. You still want to provide as much security as possible for your user's credentials, because that information is valuable to them and to those who would exploit it.

Even though you don't want to spend the money to secure your content, you still want it only accessible to credentialed users. So, instead of making users create a username/password, which would be worth protecting, just have them log in with their email address.

Your content and the email address are accessible to third parties of sufficient skill and motivation, but from what you've said, your content probably isn't worth that amount of effort, and their email address isn't that sensitive. But you still get to have a login gateway between the world and your content, and you can utilize a double opt-in to limit spam, etc. You can easily expand such a system to include a username/password and use SSL if your content grows to require it.

这篇关于数据传输和密码加密方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！