PROSAGA码农传奇-云鉴权-使用Windows帐户SID作为安全令牌

<div class =“post-text”itemprop =“text”>
  
    对，这里有 - 这是一个很长的答案......
  
  
    执行此操作的问题是，如果您需要代表他们执行操作（即冒充该用户），那么持久保存SID并不足以能够重新验证用户 - 因为您需要提供操作系统安全令牌。如果您只有SID，那么在这种情况下您仍需要密码 - 除非您在AD商店中使用可逆加密，我非常怀疑这种情况 - 并且当然希望它不是！
  
  
    除此之外，还有一个问题是，一旦加密该SID并将其发回，它就可能是安全的线上传输（只要我们假设HTTPS始终是安全的），而不是一旦它在客户端机器上。
  
  
    有人可以窃取加密的SID并开始发出请求，就好像他们是那个用户一样。
  
  
    在我看来，如果您使用AD作为后端身份验证存储，那么您应该仅使用Negotiate或Kerberos身份验证。然后，它产生的票据可用于在需要时模拟用户;而且我不相信它们会被盗（尽管在安全领域，几乎所有技术都可能被盗）。
  
  
    但是，您可能会使您的Web服务非常难以使用 - 我当然不会考虑为这些协议编写自己的客户端。
  
  
    在我说出如果遇到这个问题我可能会做什么之前，我首先要说的不是
    的
      真
    </强>
     安全 - 对于有人捣乱的同时还要删除实际用户的令牌关联（加密信息背后的模式是黑客最好的朋友），这有点麻烦。之后我还列出了其他警告：
  
  <UL>
    <LI>
      
        使用AD作为身份验证方法，但不再需要，单独跟踪身份验证会话，并为他们提供与AD SID无关的唯一密钥 - guid或类似的东西。这样，每次用户进行身份验证时，他们都会获得不同的核心会话ID。
      
    </LI>
    <LI>
      
        我会在每个会话中创建它创建的时间以及加密安全的唯一标记
        的
          随机
        </强>
         盐（一种随机数 - 虽然它没有在这里以同样的方式使用
        <a href="http://en.wikipedia.org/wiki/Cryptographic_nonce" rel="noreferrer">
          维基百科
        </A>
         描述它。使用
        <a href="http://msdn.microsoft.com/en-us/library/system.security.cryptography.rngcryptoserviceprovider.aspx" rel="noreferrer">
          RNGCryptoServiceProvider
        </A>
         为了这）。我还会在其中包含一些（但不是全部）有关客户端（ip，用户代理）的信息。
      
    </LI>
    <LI>
      
        然后，我将首先构造一个令牌作为将所有这些信息组合在一起的字符串，然后使用或者加密它
        的
          
            至少
          
        </强>
         该
        <a href="http://msdn.microsoft.com/en-us/library/system.security.cryptography.rijndael.aspx" rel="noreferrer">
          Rijndael算法
        </A>
        <a href="http://msdn.microsoft.com/en-us/library/system.security.cryptography.symmetricalgorithm.aspx" rel="noreferrer">
          SymmetricAlgorithm
        </A>
         使用128位IV和256位密钥实现（两者都必须保持非常安全，并且应该使用
        <a href="http://msdn.microsoft.com/en-us/library/system.security.cryptography.rngcryptoserviceprovider.aspx" rel="noreferrer">
          RNG
        </A>
        ！）。
      
    </LI>
  </UL>
  
    您将此发送回客户端，然后他们在其请求中使用它（直到它过期 - 它绝对必须这样做）。
  
  
    当您收到令牌时
  
  <UL>
    <LI>
      解密它，小心黑客可以生成加密值，破坏解密例程并抛出必须隐藏的异常。
    </LI>
    <LI>
      验证会话ID，时间戳，唯一编号和客户端信息是否与创建会话时记录的内容相匹配。如果出现任何问题，您会立即使会话失效。过期后续请求的过期会话甚至不会被验证，它们只会生成403.如果您使用网络信息来保护令牌，这将意味着如果用户在漫游网络上使用该服务将会遇到问题。
    </LI>
  </UL>
  
    身份验证会话永远不应该是开放式的 - 它们应该具有到期时间以防止非常旧的令牌能够被使用。
  
  
    当然，一直使用HTTP也是不言而喻的。
  
  
    所有这一切 - 您选择的身份验证等应该与传输的数据类型和人们可以做的事情成比例。如果黑客不会对您的服务感兴趣;或者如果环境完全是内部的，那么就用你原来的想法来破解。
  
  <H1>
    CAVEATS
    
      鈭瀄[R
    
    ！
  </H1>
  
    （那是无限的力量）
  
  
    虽然我已经提出了这个解决方案，但由于很多原因它并不安全，如果涉及任何真正的秘密，我就不会使用它。
  
  
    它依赖于HTTPS来验证服务器到客户端 - 这在客户端移交用户名和密码组合之前非常重要。拿走它然后它会中断，如果你操纵客户端计算机上的证书链也可以完全避开。它还依赖于HTTPS通道来保护传输中的用户名/密码组合。
  
  
    我们应该更进一步，在请求上引入消息编号和签名，以确保客户端
    的
      仍然
    </强>
     他们表现自己是因为IP地址和标题容易被欺骗。我们也应该考虑使用大型素数的非对称加密和所有用于密码传输的爵士乐，甚至在考虑HTTP之前。
  
  
    所以，基本上，如果它是安全关键 - 忽略我并咨询专家 - 
    
      不要尝试自己动手，因为你会弄错
    
    。
  
  
    如果你只是被一个12岁的怪人攻击，而不是因为这是12岁的孩子所做的，那么我的解决方案可能太沉重了你也可以选择你的想法。
  
  
    无论哪种方式 - 我不保证会发生什么/可能会发生什么，我想在某种程度上，这个现在非常长的答案实际上是在说你们都听我说话而忽略了我的危险:)
  
</DIV>