Two-way password encryption without ssl我正在使用basic-auth twitter API(不再可用)将twitter与我博客的评论系统集成。这样做以及其他许多Web API的问题在于，它们需要用户的用户名和密码才能执行任何有用的操作。我不想处理安装SSL证书的麻烦和费用，但是我也不想以明文形式通过网络传递密码。 我想我的一般问题是：如何通过不安全的通道发送敏感数据？ 这是我当前的解决方案，我想知道其中是否有孔： 最终结果是仅加密的密码通过网络发送，并且密钥仅使用一次，并且从未与密码一起发送。问题解决了吗？
这避免了通过网络以明文形式发送密码，但是它要求您通过网络以明文形式发送密钥，这样任何窃听者都可以对密码进行解密。 之前已经有人说过，我再说一遍：不要试图组成自己的加密协议！已经建立了针对此类事物的已建立协议，这些协议已由专业人员创建，同行评审，殴打，黑客入侵，戳戳和劝诱，请使用它们！没有一个人能够比整个密码和安全社区共同努力提出更好的建议。 您的方法有一个缺陷-如果有人要拦截对用户的密钥传输以及用户的加密回复，则他们可以解密该回复并获取用户的用户名/密码。 但是，有一种方法可以在不安全的介质上安全地发送信息，只要该信息不能在传输过程中被修改(称为Diffie-Hellman算法)即可。基本上，两方都可以根据他们的对话来计算用于加密数据的共享密钥-但是观察者没有足够的信息来推断密钥。 设置客户端和服务器之间的对话可能很棘手，并且比仅将SSL应用于您的站点要花费更多的时间。您甚至不必为此付费-您可以生成提供必要加密的自签名证书。这不能防止中间人攻击，但是Diffie-Hellman算法也不能。 您不必在服务器上拥有证书；客户端是否愿意与未经身份验证的服务器对话取决于客户端。仍然可以执行密钥协商以建立专用信道。但是，将私有凭据发送到未经身份验证的服务器并不安全，这就是为什么您在实践中看不到SSL以这种方式使用的原因。 要回答您的一般问题：您只需发送它。我认为您真正的普遍问题是："如何通过不安全的通道发送敏感数据，并确保其安全？"你不能。 这听起来像是您认为安全性不值得每个证书每月花费10到20美元，并且保护Twitter密码确实是正确的。那么，为什么要花时间提供安全感呢？只需向您的用户明确表示他们的密码将以明文形式发送，让他们自己选择。 API和OAuth 首先，正如其他人所说，您不应使用用户密码来访问API，而应获得OAuth令牌。这样，您就可以代表该用户采取行动，而无需他们的密码。这是许多API使用的常见方法。 密钥交换 如果您需要解决在不安全的连接上交换信息的更一般的问题，则有其他答案提到的几种密钥交换协议。 通常，密钥交换算法可以防止窃听，但是由于它们无法验证用户的身份，因此容易受到中间人攻击。 来自Diffie Hellman上的Wikipedia页面：
在某些情况下，即使攻击者能够插入自己的身份(签名密钥)代替发送者或接收者，STS也不安全。 身份和验证 这正是SSL旨在解决的问题，方法是建立"受信任的"签名机构的层次结构，该层次结构在理论上已验证谁拥有域名等，连接到网站的人可以验证其确实与之通信该域的服务器，而不是中间位置放置中间服务器的服务器。 您可以创建一个自签名证书，该证书将提供必要的配置以加密连接，但出于与未经身份验证的Diffie-Hellman密钥交换不会相同的原因，不会保护您免受中间攻击。 您可以从https://www.startssl.com/获得1年有效的免费SSL证书-我将其用于我的个人网站。不管这意味着什么，他们都没有那么"受信任"，因为他们只对申请者进行自动检查，但它是免费的。也有一些服务的成本非常低(从英国的123-Reg每年大约10英镑)。 在客户端和服务器之间发送密钥时，该密钥为明文，可能会被截取。将其与密码的加密文本结合在一起，然后密码将被解密。 Diffie-Hellman是一个很好的解决方案。如果只需要对它们进行身份验证，而实际上不传输密码(因为该密码已存储在服务器上)，则可以使用HTTP摘要式身份验证或其中的一些变体。 那么这怎么安全呢？即使您可能已经保护了浏览器<>您的服务器的安全，那其余的Internet(服务器<>推特)又如何呢？ 恕我直言，要求其他服务的用户名和密码并要求人们输入是不可接受的。而且，如果您非常在意-请不要整合它们，直到他们明白自己的行为并重新启用OAuth。 (他们支持了一段时间，但几个月前将其禁用。) 同时，为什么不提供OpenID？每个Google，Yahoo！，VOX等帐户都有一个。人们可能没有意识到这一点，但是他们已经拥有OpenID的机会确实非常高。检查此列表以了解我的意思。 客户端javascript安全性的问题在于，攻击者可以在传输过程中将javascript修改为简单的{return input;}，从而使您的安全性备受争议。解决方案：使用浏览器提供的(即未传输的)RSA。据我所知，尚不可用。 我采用了另一种方法 这适用于密码传输。将其用于数据意味着将最终的哈希作为明文的加密密钥，并生成随密码文本传输到服务器的随机初始化向量。 对此有何评论？ 我有一个类似的问题(想要在不支付ssl证书的情况下加密表格中的数据)，所以我做了一些狩猎，发现了这个项目：http://www.jcryption.org/ 我还没有使用过它，但是它看起来很容易实现，我想在这里共享它，以防其他人正在寻找类似的东西并像我一样在此页面上找到自己。 如果您不想使用SSL，为什么不尝试使用其他协议，例如kerberos？ 基本概述如下： 或者，如果您想更深入一点，请参阅 到OLI 例如，在您的请求中，我位于同一子网中且具有同一路由器，因此我在工作中得到的IP与我的同事的IP相同。我在浏览器中打开相同的URL，因此服务器使用相同的ip生成时间戳，然后使用tcp / ip dump从我的同事连接中嗅探哈希或非哈希密码。我可以嗅出他发送的所有内容。因此，我从他的形式中获得了所有哈希，并且您也拥有了时间戳(我)和相同的IP。所以我使用发布工具发送所有内容，嘿，我正在登录。 自签名的ssl证书不花钱。对于免费的Twitter服务，对用户来说可能就好了。
具有预共享的密钥。这是您在建议的解决方案中尝试的方法，但是您不能通过不安全的通道发送该密钥。有人提到了DH，它将帮助您协商密钥。但是SSL的另一部分功能是提供身份验证，以防止中间人攻击，以便客户端知道他们正在与打算与之通信的人协商密钥。 Chris Upchurch的建议确实是99.99％的工程师唯一的好答案-不要这样做。让其他人使用它并使用他们的解决方案(例如编写SSL客户端/服务器的人)。 我认为这里的理想解决方案是让Twitter支持OpenID，然后再使用它。 |
