我正在使用basic-auth twitter API(不再可用)将twitter与我的博客评论系统集成.这个以及许多其他Web API的问题在于它们需要用户的用户名和密码来做任何有用的事情.我不想处理安装SSL证书的麻烦和成本,但我也不希望以明文形式通过网络传递密码.
我想我的一般问题是:如何通过不安全的渠道发送敏感数据?
这是我目前的解决方案,我想知道它是否有任何漏洞:
在服务器上生成一个随机密钥(我正在使用php).
将密钥保存在会话中,并在javascript变量中输出密钥.
在表单提交时,在javascript中使用Triple DES并使用密钥加密密码.
在服务器上,使用会话中的密钥解密密码,然后销毁会话.
最终结果是只有加密的密码通过网络发送,密钥只使用一次,永远不会随密码一起发送.问题解决了?
在服务器上生成一个随机密钥(我正在使用php).
将密钥保存在会话中,并在javascript变量中输出密钥.
在表单提交时,在javascript中使用Triple DES并使用密钥加密密码.
这样可以避免通过网络以明文形式发送密码,但它要求您通过网络以明文形式发送密钥,这样任何人都可以通过窃听来解密密码.
之前已经说过,我会再说一遍:不要试图编写自己的加密协议!已经建立了一些既定的协议,这些协议已被创建,同行评审,击败,黑客攻击,专业人员戳戳和推动,使用它们! 没有人能够提出比整个加密和安全社区更好的东西.
你的方法有一个缺陷 - 如果有人拦截密钥传输给用户和用户的加密回复,他们可以解密回复并获得用户的用户名/密码.
但是,有一种方法可以通过不安全的介质安全地发送信息,只要该信息不能在传输过程中被修改,称为Diffie-Hellman算法.基本上,双方能够根据他们的对话计算用于加密数据的共享密钥 - 但是观察者没有足够的信息来推断密钥.
设置客户端和服务器之间的对话可能会非常棘手,而且比简单地将SSL应用到您的站点要花费更多时间.您甚至不必为此付费 - 您可以生成提供必要加密的自签名证书.这不会防止中间人攻击,但Diffie-Hellman算法也不会.
您不必在服务器上拥有证书; 它取决于客户端是否愿意与未经身份验证的服务器通信.仍然可以执行密钥协议以建立私人频道.将私有凭证发送到未经身份验证的服务器是不安全的,这就是为什么在实践中看不到SSL以这种方式使用的原因.
回答你的一般问题:你只需发送它.我认为你真正的一般性问题是:"我如何通过不安全的渠道发送敏感数据并保持安全?" 你不能.
听起来你已经决定安全性不值一个证书每月10-20美元的成本,并且为了保护Twitter密码,这可能是真的.那么,为什么要花时间提供安全的幻觉呢?只需向您的用户明确说明他们的密码将以明文形式发送,并让他们自己做出选择.