我正在使用basic-auth twitter API（no longer available）将twitter与我博客的评论系统集成。这个以及许多其他Web API的问题在于它们需要用户的用户名和密码来做任何有用的事情。我不想处理安装SSL证书的麻烦和成本，但我也不希望以明文形式通过网络传递密码。
我想我的一般问题是：如何通过不安全的渠道发送敏感数据？
这是我目前的解决方案，我想知道它是否有任何漏洞：
最终结果是只有加密的密码通过网络发送，密钥只使用一次，永远不会随密码一起发送。问题解决了吗？
答案 0 :(得分：34)
- 在服务器上生成一个随机密钥（我正在使用php）。
- 将密钥保存在会话中，并在javascript变量中输出密钥。
- 在表单提交时，在javascript中使用Triple DES并使用密钥加密密码。
这样可以避免通过网络以明文形式发送密码，但它要求您通过网络以明文形式发送密钥，这样任何人都可以通过窃听来解密密码。
之前已经说过了，我会再说一遍：不要试图制作自己的加密协议！已经建立了一些既定的协议，这些协议已被创建，同行评审，击败，攻击，戳戳和专业人士刺激，使用它们！没有人能够提出比整个加密和安全社区一起工作更好的东西。
答案 1 :(得分：10)
你的方法有一个缺陷 - 如果有人拦截密钥传输给用户和用户的加密回复，他们可以解密回复并获得用户的用户名/密码。
但是，有一种方法可以通过不安全的媒体安全地发送信息，只要该信息不能在传输过程中被修改为Diffie-Hellman algorithm。基本上，双方能够根据对话计算用于加密数据的共享密钥 - 但观察者没有足够的信息来推断密钥。
设置客户端和服务器之间的对话可能会非常棘手，而且比简单地将SSL应用到您的站点要花费更多时间。您甚至不必为此付费 - 您可以生成提供必要加密的自签名证书。这不会防止中间人攻击，但Diffie-Hellman算法也不会。
答案 2 :(得分：6)
您的服务器上没有证书;它取决于客户端是否愿意与未经身份验证的服务器通信。仍然可以执行密钥协议以建立私人频道。将私有凭证发送到未经身份验证的服务器是不安全的，这就是为什么在实践中看不到SSL以这种方式使用的原因。
回答您的一般问题：您只是发送它。我认为您的真正的一般问题是：“如何通过不安全的渠道发送敏感数据 - 并保持安全吗？“ 你不能。
听起来你已经确定安全性不值得证书每月10-20美元的费用，并且为了保护Twitter密码，这可能是真的。那么，为什么要花时间提供安全的幻觉呢？只需向用户说明他们的密码将以明文形式发送，让他们自己选择。
答案 3 :(得分：2)
那么这怎么更安全？即使你可能已经保护了浏览器＆lt;＆gt;你的服务器，那么互联网的其余部分（你的服务器＆lt;＆gt; twitter）呢？
恕我直言，要求提供其他服务的用户名和密码并希望人们输入该服务是不可接受的。如果你关心那么多 - 在他们直截了当并重新启用OAuth之前，不要整合它们。 （他们支持了一段时间，但几个月前禁用了它。）同时，为什么不提供OpenID？每个Google，Yahoo！，VOX等帐户都有一个。人们可能没有意识到这一点，但他们已经拥有OpenID的机会非常非常高。 Check this list看看我的意思。
答案 4 :(得分：2)
当在客户端和服务器之间发送密钥时，它是明文并且可以拦截。将其与密码的加密文本相结合，密码将被解密。
Diffie-Hellman是一个很好的解决方案。如果您只需要对它们进行身份验证，而不是实际传输密码（因为密码已存储在服务器上），那么您可以使用HTTP Digest Authentication或其中的某些变体。
答案 5 :(得分：2)
API和OAuth
首先，正如其他人所说，你不应该使用用户的密码来访问API，你应该得到OAuth token。这将允许您代表该用户行事而无需其密码。这是许多API使用的常用方法。
密钥交换
如果您需要解决通过不安全连接交换信息的更一般问题，那么其他答案中提到了几种密钥交换协议。
一般来说，密钥交换算法对窃听者是安全的，但由于它们不会对用户的身份进行身份验证，因此很容易受到中间人攻击。
来自Diffie Hellman上的维基百科页面：
在原始描述中， Diffie-Hellman交换本身并不提供身份验证 沟通各方因此容易受到影响 中间人攻击。中间的人可以建立两个 不同的Diffie-Hellman密钥交换，一个与Alice和另一个 与鲍勃一起，有效地伪装成爱丽丝到鲍勃，反之亦然， 允许攻击者解密（并读取或存储）然后重新加密 他们之间传递的消息。一种验证方法 通常需要相互沟通的各方来防止 这种类型的攻击。 Diffie-Hellman的变体，例如STS，可能是 反而用来避免这些类型的攻击。</ p>
在某些情况下，攻击者能够插入自己的身份（签名密钥）代替发送方或接收方，即使STS也不安全。
身份和身份验证
这正是SSL旨在解决的问题，通过建立“受信任”签名机构的层次结构，理论上 验证谁拥有域名等，连接到网站的人可以验证他们确实正在与该域的服务器进行通信，而不是与介于两者之间的中间人进行通信。
您可以创建一个自签名证书，该证书将提供加密连接所需的配置，但不会保护您免受中间人攻击，原因与未经身份验证的Diffie-Hellman密钥交换不会相同。
您可以从https://www.startssl.com/获得有效期为1年的免费SSL证书 - 我将其用于我的个人网站。无论这意味着什么，它们都不是那么“可信”，因为它们只会对申请一个人的人进行自动检查，但它是免费的。还有一些服务成本很低（英国123-Reg每年10英镑）。
答案 6 :(得分：1)
我实施了不同的方法
这适用于密码传输。将其用于数据意味着使用最终散列作为纯文本的加密密钥，并生成随密文传输到服务器的随机初始化向量。
对此有何评论？
答案 7 :(得分：1)
客户端javascript安全性的问题在于，攻击者可以将传输中的javascript修改为简单的{return input;}，从而使您精心设计的安全性无人问津。解决方案：使用浏览器提供的（即未传输）RSA。据我所知，还没有。
答案 8 :(得分：0)
如何通过发送敏感数据 不安全的渠道
使用预共享密钥。这是您在建议的解决方案中尝试的内容，但您无法通过不安全的渠道发送该密钥。有人提到DH，这将帮助你谈判一把钥匙。但SSL所做的另一部分是提供身份验证，以防止中间人攻击，以便客户端知道他们正在与他们打算与之通信的人协商密钥。
Chris Upchurch的建议实际上是99.99％的工程师唯一的好答案 - 不要这样做。让其他人这样做并使用他们的解决方案（就像编写SSL客户端/服务器的人一样）。
我认为这里理想的解决方案是让Twitter支持OpenID，然后再使用它。
答案 9 :(得分：0)
自签名的ssl证书不需要花钱。对于免费的Twitter服务，这可能对用户来说很好。
答案 10 :(得分：0)
TO OLI
在您的approch中，例如我在同一个子网中使用相同的路由器，所以我在工作中获得了与我的同事相同的IP。我在浏览器中打开相同的URL，因此服务器使用相同的ip生成时间戳，然后我使用tcp / ip dump从我的同事连接中嗅探散列或非散列密码。我可以嗅到他发送的一切。所以我从他的表格中得到了所有哈希，你也有时间戳（我的）和同样的ip。所以我使用post工具发送所有内容，嘿，我是loggen。
答案 11 :(得分：0)
如果您不想使用SSL，为什么不尝试其他协议，例如kerberos？
基本概述如下： http://www.kerberos.org/software/tutorial.html
或者如果你想更深入一点，请参阅 http://www.hitmill.com/computers/kerberos.html
答案 12 :(得分：0)
我有一个类似的问题（想要在不支付ssl证书的情况下加密表格中的数据）所以我做了一些狩猎并找到了这个项目：http://www.jcryption.org/
我还没有使用它，但它看起来很容易实现，并认为我会在这里分享它，以防其他任何人正在寻找类似的东西，并发现自己像我一样在这个页面上。