如何仅使用对称加密技术以安全的方式在客户端和服务器之间发送数据

时间：2017-01-11 01:36:39

标签： security cryptography encryption-symmetric

我采取以下步骤在客户端和服务器之间发送/接收数据。但我不确定所有步骤是否足够安全且无法拦截。如果有的话，请你告诉我如何修补安全漏洞？ 请注意：

  • 这是针对对称加密而不是公钥/私钥方法的全部内容。所以＆＃39;盐＆＃39;和＆＃39; entropy＆＃39;是客户端和服务器之间的秘密。
  • 由于某些原因，我不能/不能使用SSL或TLS协议。所以没有证书颁发机构等。
  • 只能使用标准的加密函数和方法（没有发明）。
  • 数据不是通过安全（HTTPS）连接发送的。
  • 我不能在这里使用会话，因为它们是两个不同的应用程序。
    •

    第一次 - 注册（用户输入新用户名和新密码）

    1. 客户端
      1. 创建用户的CSPRNG盐
        1. 在用户的机器上保存盐
      2. 在内存中创建熵（时间值为base64，例如[小时]当天] + [一年中的一天]）
      3. 发布密码（明文的base64），盐和熵到服务器
    2. 服务器端
      1. 对于收到的来自cliet的消息
        1. 检查熵是否匹配（例如，与[当天的小时]的base64相加+ [一年中的一天]）。
        2. 计算salt和密码的哈希值（SHA1）（明文的base64） - 因为必须始终在服务器上进行散列。
        3. 保存盐和计算出的数据库哈希

    下次 - 登录（用户输入他的用户名和密码）

    1. 客户端
      1. 阅读来自用户机器的盐
      2. 盐的计算哈希值（SHA1）和输入的密码（明文的base64）
      3. 发布密码（明文的base64）和salt，以及计算机对服务器的散列​​
    2. 服务器端
      1. 检索盐和存储的哈希值＆＃39;来自数据库
      2. 从收到的客户端消息
        1. 将消息拆分为3部分：password（paintext的base64）;盐; ＆＃39;收到哈希＆＃39;
        2. 比较＆＃39;收到的哈希＆＃39;使用＆＃39;存储哈希＆＃39 ;;如果匹配，则用户是真正的不是黑客

    从用户向服务器发送TemperProof queryString

    1. 客户端
      1. 从用户那里读取盐机器
      2. 在内存中创建一个熵（时间值的base64，例如[一天中的小时] + [一年中的一天]）
      3. queryString的计算哈希值（SHA1）（明文的base64，盐和熵
      4. 发布查询字符串（明文的base64），盐，熵，以及计算出的哈希值到服务器
    2. 服务器端
      1. 从数据库中检索salt
      2. 对于收到的来自cliet的消息
        1. 拆分消息分为4部分：queryString（paintext的base64）;盐;熵; ＆＃39;收到哈希＆＃39;
        2. 检查熵是否匹配（例如，与[当天的一小时]的基数64 + [一年中的一天]）。
        3. 计算哈希（ SHA1）queryString（明文的base64）和salt和entropy。
        4. 将计算出的哈希值与分割后的消息的第4部分进行比较（＆＃39;收到哈希值＆＃39;）;如果它们匹配，则queryString是真的

    从服务器向用户发送回复

    1. 服务器端
      1. 使用数据库查询计算答案< / li>
      2. 从数据库中检索盐
      3. 在内存中创建熵（时间值的base64，例如[一天中的小时] + [一年中的一天]）
      4. 计算答案的哈希（SHA1）（明文的base64），盐和熵
      5. 将答案（明文的base64），盐，熵和计算的哈希值计算到客户端
    2. 客户端
      1. 从用户计算机读取盐
      2. 创建熵记忆（时间值的base64，例如[一天中的小时] + [一年中的一天]）
      3. 将收到的消息拆分为4个部分：answer（paintext的base64）;盐;熵; ＆＃39;收到哈希＆＃39;
      4. 检查熵是否匹配（例如，与[当天的一小时]的基数64 + [一年中的一天]）。
      5. 计算哈希（答案的SHA1）（明文的base64）和盐和熵。
      6. 将计算的哈希与分割的消息的第4部分进行比较（＆＃39;接收的哈希＆＃39;）;如果他们匹配，答案是真的

    我认为以下几个方面存在缺陷。你能告诉我们如何解决这些问题并指出其他可能的漏洞吗？

      A）第一次 - 注册：如果他在步骤1.3中找到熵，黑客可以发布垃圾填满数据库
      B）下次 - 登录：我想不出在步骤​​1.2中为散列密码添加熵的方法，因为那时我无法与服务器数据库中的那个进行比较2.2.2

      由于

    2 个答案:

    答案 0 :(得分：2)

    如果您完全关心安全问题，请立即停止......

    你需要做什么：

    1）忘记设计自己的加密协议......依靠众所周知的加密ALSO意味着你不要设计那种东西

    2）分层思考......你需要在将它们从A运输到B时保守秘密...这意味着你有一个传输层...如果你想要那个安全的，有一个名字那...
    T ransport L ayer S ecurity - ＆gt; https://en.wikipedia.org/wiki/Transport_Layer_Security

    3）当你在这里做出类似假设时，我有2个应用程序，所以我不能有会话＆＃34;，请提供为什么你认为它是那样...当你想到像单点这样的东西 - 你可以让很多应用程序在一堆不同的平台上共享一种身份验证方法甚至会话数据...也许只是你不知道你实际上可以有会议......

    4）阅读你使用的术语......你误解了熵......没有办法检查熵是否匹配＆＃34; ...加密相关案例中的熵意味着对函数的不可预测输入的随机性...如果你有类似日期和时间的东西，即使你散列它，它可能看起来随机......但它是非常的具有时钟的人可以预测...如果通信可以与值的创建时间相关，那么如果基于时钟，则您的值不包含大量熵...再次，不设计您自己的这里的东西，去寻找提供可靠，加密安全随机性的熵源（CSPRNG ......不仅仅是PRNG）

    5）...你误解/误用盐... 这在客户端机器上无需生成 这不需要保留在客户机上

    7）密码哈希 再次......不要在这里想出你自己的东西...... 为每个密码创建一个足够长的随机盐（至少哈希长度）。使用具有高迭代计数参数的慢速哈希函数，如PBKDF2。原因是测试密码变得很慢......你的服务器必须为每次登录尝试计算一次......攻击者必须为每次密码测试尝试计算这个...你可以负担得起测试200ms ......对于攻击者而言，这意味着需要更多硬件才能破解密码存储......

    <强> UPD：
    你想要它，你得到它......

    中间人对您的架构的概念证明：

    客户：alice
    服务器：bob
    攻击者/窃听者：前夕

    1. alice使用您的注册服务并创建帐户
      1.1 alice创建一个CSPRNG盐并以安全的方式存储 1.2 alice收集任意数量的熵并用base64编码 1.3 alice发送密码（明文的base64），盐和熵发送到bob ------------截获-------------
    2. 前夕拦截了爱丽丝和鲍勃之间的交流，并获得了...的知识 2.1 ...基本64位编码密码 - ＆gt; base64 decode - ＆gt;明文密码
      2.2 ...盐
      2.3 ......熵值
      2.4 alice转发截获的通信而不改变bob

      3. ---协议破碎---
      现在，bob绝不能在所有进一步的沟通中区分alice和eve

      upd2：

      查看您转移的（明文）消息：
      登录：
      将密码（明文的base64）和salt以及计算的哈希发布到服务器 从用户向服务器发送queryString：
      将查询字符串（明文的base64），salt和entropy以及计算出的哈希值发布到服务器 答案：
      将答案（明文的base64），盐，熵和计算的哈希发布到客户端

      现在，对于任何这些消息，让我们看看有恶意的人会从中获取哪些信息：

      所有信息都是明文，这意味着所有信息...... 对于登录，我们获得明文密码，意味着从现在起攻击者可以识别为有效用户

      为查询字符串和答案提供了一种方法来查看请求/答案是否未得到缓和。

      因此，如果攻击者现在拦截您的通信，他怎么能在不被注意的情况下更改查询字符串？ 攻击者分裂你的消息，并改变他/她想要的任何东西 然后他/她将forged_hash计算为sha1（salt_from_the_original_message，tampered_querystring）并将base64（tampered_querystring），salt_from_the_original_message，entropy_from_original_message，forged_hash发送到服务器......

      答案是同一笔交易：

      攻击者截获原始答案，更改答案中的任何内容并根据已知信息（更改和原始盐）重新计算哈希值

    答案 1 :(得分：0)

    1. 解决方案是使用HTTPS withTLS 1.2并固定证书，有免费的证书解决方案。

    2. 使用散列（在本例中为SHA1）来保护密码在一段时间内并不是一个好的安全措施。有关我的参考，请参阅DRAFT NIST Special Publication 800-63B Digital Authentication Guideline。

    3. 密码必须使用迭代的HMAC保护，而不是单个哈希。有关密码的更多信息，请参阅Jim Fenton的Toward Better Password Requirements，特别参见幻灯片23。这似乎与Pluralsight培训不一致，最佳实践随着时间的推移而发生变化。

    相关问题
    最新问题