我正在使用basic-auth twitter API(不再可用)将twitter与我的博客的评论系统集成。这样做以及其他许多Web API的问题在于，它们需要用户的用户名和密码才能执行任何有用的操作。我不想处理安装SSL证书的麻烦和费用，但是我也不想以明文形式通过网络传递密码。

我想我的一般问题是：如何通过不安全的通道发送敏感数据？

这是我当前的解决方案，我想知道其中是否有任何漏洞：

• 在服务器上生成一个随机密钥(我正在使用php)。
• 将密钥保存在会话中，并在javascript变量中输出密钥。
• 在提交表单时，使用Javascript中的Triple DES和密钥来加密密码。
• 在服务器上，使用会话中的密钥解密密码，然后销毁会话。

最终结果是仅加密的密码通过网络发送，并且密钥仅使用一次，并且从未与密码一起发送。问题解决了？

解决方案

回答

如果有人要拦截将密钥传输给用户以及用户的加密回复，则他们可以解密回复并获取用户的用户名/密码，那么方法就会存在缺陷。

但是，有一种方法可以在不安全的介质上安全地发送信息，只要该信息不能在传输过程中被修改(称为Diffie-Hellman算法)即可。基本上，两方都可以根据他们的对话来计算用于加密数据的共享密钥，但是观察者没有足够的信息来推断密钥。

但是，设置客户端和服务器之间的对话可能很棘手，并且比仅将SSL应用于站点要花费更多的时间。我们甚至不必付费，我们可以生成提供必要加密的自签名证书。这不能防止中间人攻击，但Diffie-Hellman算法也不能。

回答

Generate a random key on the server (I'm using php).
  Save the key in a session and also output the key in a javascript variable.
  On form submit, use Triple DES in javascript with the key to encrypt the password.

这样可以避免通过网络以明文形式发送密码，但是它要求我们通过网络以明文形式发送密钥，这样任何窃听者都可以对密码进行解码。

之前有人说过，我再说一遍：不要试图组成自己的加密协议！已经建立了针对此类事物的已建立协议，这些协议已由专业人员创建，同行评审，殴打，黑客入侵，戳戳和劝诱，请使用它们！没有一个人能够比整个密码和安全社区共同努力提出更好的建议。

回答

那么，这怎么更安全呢？即使我们可能已经保护了浏览器<>服务器的安全，但Internet的其余部分(服务器<> twitter)又如何呢？

恕我直言，要求其他服务的用户名和密码并要求人们输入是不可接受的。而且，如果我们非常在意，请不要整合它们，直到他们明白自己的行为并重新启用OAuth。 (他们支持了一段时间，但几个月前将其禁用。)

同时，为什么不提供OpenID？每个Google，Yahoo！，VOX等帐户都有一个。人们可能没有意识到这一点，但是他们已经拥有OpenID的机会确实非常高。检查此列表以了解我的意思。

回答

当在客户端和服务器之间发送密钥时，密钥是明文，可能会被截取。将其与密码的加密文本结合在一起，然后密码将被解密。

Diffie-Hellman是一个很好的解决方案。如果我们只需要对它们进行身份验证，而实际上不传输密码(因为该密码已存储在服务器上)，则可以使用HTTP摘要式身份验证或者其中的一些变体。

回答

我们不必在服务器上拥有证书；客户端是否愿意与未经身份验证的服务器对话取决于客户端。仍然可以执行密钥协商以建立专用通道。但是，将私有凭据发送到未经身份验证的服务器并不安全，这就是为什么我们在实践中看不到SSL以这种方式使用的原因。

要回答一般问题：我们只需发送它。我认为我们真正的普遍问题是：如何通过不安全的通道发送敏感数据并确保其安全？你不能

听起来我们似乎已经决定，安全性不值得每个证书每月花费1020美元，并且为了保护Twitter密码，这可能是正确的。那么，为什么要花时间提供安全感呢？只需向用户明确表示他们的密码将以明文形式发送，让他们自己选择。

回答

我采用了另一种方法

• 服务器：存储在数据库中的用户名和密码哈希
• 服务器：发送带有要求密码的表单的质询，将其与时间戳和客户端的IP地址一起存储在会话中
• 客户端：对密码进行哈希处理，使用concat挑战|用户名|密码哈希，再次对其进行哈希处理并将其发布到服务器
• 服务器：验证时间戳，IP，进行相同的串联/哈希处理并进行比较

这适用于密码传输。将其用于数据意味着将最终的哈希用作明文的加密密钥，并生成随密码文本传输到服务器的随机初始化向量。

对此有何评论？

回答

How can I send sensitive data over an
  insecure channel

具有预共享的密钥。这是我们在建议的解决方案中尝试的方法，但是我们不能通过不安全的通道发送该密钥。有人提到DH，它将协商密钥。但是SSL的另一部分功能是提供身份验证，以防止中间人攻击，从而使客户端知道他们正在与打算与之通信的人协商密钥。

Chris Upchurch的建议确实是唯一的好答案，因为99.99％的工程师不这样做。让其他人使用它并使用他们的解决方案(例如编写SSL客户端/服务器的人)。

我认为这里的理想解决方案是让Twitter支持OpenID，然后再使用它。

回答

自签名的ssl证书不花钱。对于免费的推特服务，这可能对用户来说很好。

回答

到奥利

例如，在申请中，我位于同一子网中且具有同一路由器，因此我在工作中得到的IP与我的同事相同。我在浏览器中打开相同的URL，因此服务器使用相同的ip生成时间戳，然后使用tcp / ip dump从我的同事连接中嗅探哈希或者非哈希密码。我可以嗅出他发送的所有内容。因此，我从他的形式中获得了所有哈希，并且我们也拥有了时间戳(我)和相同的IP。因此，我使用发布工具发送了所有内容，嘿，我正在登录。