Honey Encrypted Password Managers

A look at turning offline attacks on password managers into online attacks that can be detected.

The current trends of client side encrypted password managers and phishing-resistant authentication, using security keys/passkeys, are great. There is still room for improvement. This post will present a way to turn offline attacks on password managers into online attacks that can be rate limited or detected. 

When encrypting data, a key of some length is required, e.g. 256 bits for AES-256. Ideally, the key would be generated from a high-entropy source like a True Random Number Generator (TRNG). Sometimes a much lower entropy passphrase is used to derive a key using a Key Derivation Function (KDF), e.g. Argon2id. The KDF should make brute-force attacks impractical.

Both high-entropy secrets and KDFs are widely deployed in practice. Another approach to mitigate brute-force attacks is to use Honey Encryption: if the ciphertext is decrypted using an incorrect key, the resulting plaintext should look plausible. This way the attacker should not immediately know if they correctly guessed the right key.

For password managers, a passphrase is often used to unlock all the passwords. The passphrase, sometimes combined with a high-entropy secret, is run through a KDF to get the key. The use of Message Authentication Codes (MACs) can typically be used to know if the right passphrase is provided, without looking at the content itself.

We can use honey encryption to make an incorrect guess of the passphrase result in passwords that are indistinguishable from the real ones. If the passwords are used in a service that can rate limit and log failed attempts, we can turn an offline brute-force attack into an online attack.

One approach is to store 128 bits of entropy E for each password, then use a transform T, such that T(E) is a valid password for the given service. We can then encrypt the entropy E without using a MAC, e.g. using AES in CTR mode. Decrypting the entropy with the wrong key should produce an entropy E’ that is indistinguishable from the actual entropy E, and T(E’) will produce a valid password that can only be verified by using it online.

As password metadata like names and URLs cannot as easily be honey encrypted, it would be simpler so encrypt these separately. They could be protected by something like a device key.

In order to get high quality alerting on failed passwords, it must be distinguishable from other attacks and accidental use. The entropy of the honey encrypted passwords would probably be higher than passwords used in password spraying and password reuse attacks. If the password manager and online login service cooperated it could be possible to specifically detect invalid passphrase guesses. Honeytokens stored in the password manager could be used to improve detection further.

Edit: The approach is not without drawbacks. If one of the passwords can be easily verified offline/online, it would break. Also if there are a lot of passwords, the attempts could be spread out to have fewer attempts at each. One approach to mitigate this is having a separate password type, that could potentially be limited to as set of trusted online use cases.