多年来，我不止一次遇到过这种情况。您有一堆与用户相关的数据要从一个应用程序发送到另一个应用程序。第二个应用程序应该“信任”这个“ token ”并使用其中的数据。 token 中包含时间戳以防止盗窃/重用攻击。无论出于何种原因(让我们在这里不用担心)已经选择了自定义解决方案，而不是像 SAML 这样的行业标准。
对我来说，对数据进行数字签名似乎是您想要的。如果数据需要保密，那么您也可以对其进行加密。
但是我经常看到的是，开发人员将使用对称加密，例如AES。他们假设除了使数据“保密”之外，加密还提供 1) 消息完整性和 2) 信任(来源身份验证)。
我怀疑这里存在固有弱点是否正确？ 从表面上看，如果对称 key 管理得当，它似乎确实有效。缺少那个 key ，我当然不知道如何修改加密 token ，或者在拦截几个 token 后发起某种加密攻击。但是，更老练的攻击者能否在这里利用某些东西？
最佳答案
部分取决于加密模式。如果你使用欧洲央行(你真丢脸!)我可以交换块，改变消息。 Stackoverflow got hit by this very bug .
威胁较小 - 没有任何完整性检查，我可以执行中间人攻击，并交换各种位，您将收到它并尝试对其进行解密。你当然会失败，但尝试可能会有所启发。 “Bernstein(利用缓存和微架构特性的组合)和 Osvik、Shamir 和 Tromer(利用缓存冲突)依赖于基于大量随机测试获取统计数据”的侧信道攻击。 1脚注文章是由一位比我更重要的密码学家撰写的，他建议使用 MAC 减少攻击面:
if you can make sure that an attacker who doesn't have access to your MAC key can't ever feed evil input to a block of code, however, you dramatically reduce the chance that he will be able to exploit any bugs
关于security - 身份验证 token 已加密但未签名 - 弱点？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1088144/