未来的CouchDB维护人员不一定保证这种行为，但受Unix password lockout feature的启发，在实践中似乎可以做到这一点，方法是至少将derived_key字段替换为一个伪值，如"*"或"!"。
例如，此用户可以通过提供特定密码登录：

{
  "_id": "org.couchdb.user:test",
  "name": "test",
  "roles": [],
  "type": "user",
  "password_scheme": "pbkdf2",
  "iterations": 10,
  "derived_key": "e7666ce1536488d8c0ceb2b2e9baf25d83e1d720",
  "salt": "8b7ea88d05181c77553169354decb0b7"
}

通过用垃圾数据替换与方案相关的字段，当CouchDB日志不记录任何特定的扰乱/崩溃时，用户将无法再登录：

{
  "_id": "org.couchdb.user:test",
  "name": "test",
  "roles": [],
  "type": "user",
  "password_scheme": "pbkdf2",
  "iterations": 10,
  "derived_key": "!",
  "salt": "-some other random nonce-"
}

但是我还没有完全确认CouchDB内部是如何处理这个问题的。我对认证逻辑以及它如何与pbkdf 2实现交互的理解是，存储的derived_key作为原始字节字符串与重新计算的字节字符串进行比较，因此不会产生冲突。因此，这应该总是禁用帐户。（与这种情况相反，比如，存储的"!"被乐观地期望为具有确定长度的十六进制，并且在解析失败或其他情况的任何情况下被悄悄地“强制”到全零的缓冲区中......那么它 * 可能 * 有可能找到输入密码，使得结果看起来正确。将salt设置为一个新的随机但有效的nonce值可能会使这种旁路在实践中受到禁止。）