一个很好的例子是 CBC 上的缺陷，在 SSL 中演示，特别是在 IMAP-over-SSL 设置中的密码恢复。请参阅有关详情。简单来说，SSL有一个 MAC，但它有一小部分是在解密之后但之前对接收到的加密数据做一些事情验证 MAC。也就是说，接收系统正在解密数据，检查填充是否正确，如果不是这样，则向对等方报告错误，然后只检查 MAC。如果 MAC 错误，则错误消息会有所不同。因此，接收方（服务器，在 IMAPS 密码恢复的情况下）泄露了一点信息，即解密后发现的填充是否正确。碰巧 SSL 使用了一种类似于 PKCS#5 中描述的填充。细节很微妙（但在数学上并不难，一旦您了解 XOR 是可交换和关联的），但它允许攻击者通过修改一些精心选择的字节来一一猜测纯数据字节。假设有相同内容的常规连接尝试（通常，Outlook Express 每 5 分钟检查一次服务器是否有新邮件），攻击者有 1/256 的机会在每个连接处猜测一个新字节。在一天结束时，瞧！一个完整的密码。

这个案例显示了在存在主动攻击者且没有 MAC 的情况下可能发生的情况，即使“无 MAC”部分非常短暂；因为 SSL有一个 MAC，只是在这个过程中检查得太晚了。更正是总是检查MAC，不管填充是否好，并用相同的错误代码报告bad padding和bad MAC（你必须检查MAC，因为当填充错误时不做可能会在这种情况下，使服务器响应速度过快，从而通过时间泄露信息）。如果没有更正，服务器会通过其行为泄露一些信息，无论是明显的错误消息，还是响应时的轻微延迟（或缺乏）。这是一点点每次尝试。然而，发起密码恢复攻击就足够了。

该攻击于 2002 年发布。然而，在 2010 年，同样的错误仍然存​​在于ASP 处理加密 cookie的方式中，允许活跃的攻击者在不到一小时的时间内劫持受保护的会话。该攻击在 2002 年被证明是可行的；2010 年，它被证明是在该领域实际应用的。

我们没有详尽的清单，列出了由于缺少 MAC 而可能发生的攻击。所以普遍的看法是，当没有专门的完整性检查时，就没有针对主动攻击者的适当安全性，这就是 MAC。常见的错误是认为在任何特定情况下，攻击者只能是被动的。有线和无线通信经常受到低功率坏人的主动攻击（例如，网吧里无聊的学生）。

在进行对称加密时，添加 MAC 的正确方法是使用组合的加密和 MAC 模式，例如GCM或EAX。这些模式依赖于分组密码（通常是 AES）。还有其他此类模式，但有些已获得专利；这两个被认为不是。

签名（相对于 MAC）是一个完全不同的问题，特别是在它们与保密的关系方面。