这些年来，我不止一次遇到过这种情况。您有一堆与用户相关的数据，要从一个应用程序发送到另一个应用程序。第二个应用程序应该“信任”这个“令牌”并使用其中的数据。令牌中包含时间戳以防止盗窃/重用攻击。无论出于何种原因（这里不用担心），都选择了自定义解决方案，而不是像 SAML 这样的行业标准。
对我来说，对数据进行数字签名似乎是你想要的。如果数据需要保密，那么您也可以对其进行加密。
但我经常看到的是开发人员会使用对称加密，例如 AES。他们假设除了使数据“保密”之外，加密还提供 1) 消息完整性和 2) 信任（源身份验证）。
我是否正确怀疑这里存在固有的弱点？从表面上看，如果对称密钥管理得当，它似乎确实有效。没有那个密钥，我当然不知道如何修改一个加密的令牌，或者在截获几个令牌后发起某种加密攻击。但是一个更老练的攻击者能够在这里利用一些东西吗？
部分取决于加密模式。如果你使用欧洲央行（你真丢脸！）我可以交换块，改变消息。 Stackoverflow 受到了这个错误的打击。
威胁更小——没有任何完整性检查，我可以执行中间人攻击，并交换各种位，你会收到它并尝试解密它。你当然会失败，但这种尝试可能会有所启发。“Bernstein（利用缓存和微架构特征的组合）和 Osvik、Shamir 和 Tromer（利用缓存冲突）依赖于基于大量随机测试获得统计数据”的侧信道攻击。1 脚注文章出自一位比我更重要的密码学家，他建议使用 MAC 减少攻击面：
但是，如果您可以确保无法访问您的 MAC 密钥的攻击者永远无法将恶意输入输入到代码块中，那么您将大大降低他能够利用任何错误的机会
是的。单独的加密不提供身份验证。如果要进行身份验证，则应使用消息身份验证代码，例如 HMAC 或数字签名（取决于您的要求）。
如果消息只是加密但未经过身份验证，则可能会发生大量攻击。这里只是一个非常简单的例子。假设消息使用CBC加密. 此模式使用 IV 来随机化密文，因此两次加密相同的消息不会导致相同的密文。现在看看如果攻击者只是修改了 IV 但保留了密文的其余部分，解密过程中会发生什么。只有解密消息的第一个块会改变。此外，正是这些位在消息中的 IV 变化中发生了变化。因此，攻击者确切地知道当接收者解密消息时会发生什么变化。例如，如果第一个块是一个时间戳，攻击者知道原始消息的发送时间，那么他可以轻松地将时间戳固定到任何其他时间，只需翻转正确的位即可。
消息的其他块也可以被操纵，尽管这有点棘手。另请注意，这不仅仅是 CBC 的弱点。OFB、CFB等其他模式也有类似的弱点。因此，期望仅加密提供身份验证只是一个非常危险的假设
对称加密方法与密钥一样安全。如果两个系统都可以得到密钥并安全地持有密钥，这很好。公钥密码学当然是更自然的选择。