This looks fairly error-prone. If you store e.g. a disk/file encryption password, or a password that leaked somewhere, this turns back into an offline attack.
Also, if you’re still going to use device keys to encrypt metadata - how do you handle that? You obviously can’t just use the same passphrase for them. Would you need to use two independent passphrases? If not, because you use some other way of safely generating per-device keys - why not use that for the passwords too?
Author here. Those are valid points; this is an idea looking for a good use case.
Regarding passwords that can be verified offline: yes, this would defeat the purpose. Having a separate password type could help mitigate this.
Regarding password leaks: yes, this would be a problem. There could be cases where it’s possible to rotate the state after a leak to prevent it from being exploited afterwards.
Regarding device keys and metadata: there are security/usability trade-offs to be made. The main idea is to turn an offline attack into an online attack. So the honey encryption might be in addition to existing techniques such as device keys, KDFs and even an additional passphrase. One approach is to use a device key protected by a TPM (with or without user interaction/biometrics) to both decrypt the metadata and provide additional entropy to produce the key for the honey encryption.
Those are valid points; this is an idea looking for a good use case.
Possibly relevant: I’ve once prototyped a hardware password manager that should be safe to use even on untrusted computers (which I personally believe is more important than protecting against offline attacks).
The idea was that you sent the name of the account to the device - e.g. dzwdz@lobste.rs, it displayed it on a screen, and if you accepted it, it sent back HMAC(deviceKey, name), which I then converted into the actual password.
I don’t really know if you could apply honey encryption there, though. The database only stored metadata, and the device itself wasn’t encrypted. Maybe it could also accept a PIN, which would get mixed into the key?
This looks fairly error-prone. If you store e.g. a disk/file encryption password, or a password that leaked somewhere, this turns back into an offline attack.
Also, if you’re still going to use device keys to encrypt metadata - how do you handle that? You obviously can’t just use the same passphrase for them. Would you need to use two independent passphrases? If not, because you use some other way of safely generating per-device keys - why not use that for the passwords too?
Author here. Those are valid points; this is an idea looking for a good use case.
Regarding passwords that can be verified offline: yes, this would defeat the purpose. Having a separate password type could help mitigate this.
Regarding password leaks: yes, this would be a problem. There could be cases where it’s possible to rotate the state after a leak to prevent it from being exploited afterwards.
Regarding device keys and metadata: there are security/usability trade-offs to be made. The main idea is to turn an offline attack into an online attack. So the honey encryption might be in addition to existing techniques such as device keys, KDFs and even an additional passphrase. One approach is to use a device key protected by a TPM (with or without user interaction/biometrics) to both decrypt the metadata and provide additional entropy to produce the key for the honey encryption.
Possibly relevant: I’ve once prototyped a hardware password manager that should be safe to use even on untrusted computers (which I personally believe is more important than protecting against offline attacks).
The idea was that you sent the name of the account to the device - e.g.
dzwdz@lobste.rs, it displayed it on a screen, and if you accepted it, it sent back HMAC(deviceKey, name), which I then converted into the actual password.I don’t really know if you could apply honey encryption there, though. The database only stored metadata, and the device itself wasn’t encrypted. Maybe it could also accept a PIN, which would get mixed into the key?