I have been learning a lot lately about password hashing since we realized our own site used an inadequate mechanism (SHA256). I am also a major fan of 1Password for password generation and management. So I held my breath while reading how to use Hashcat on 1Password data:

The reason for the high speed is what I think this might be a design flaw. Here is why:

But if you take a close look now you see these both mechanisms do not match in combination. To find out if the masterkey is correct, all we need is to match the padding, so all we need to satisfy the CBC is the previous 16 byte of data of the 1040 byte block. This 16 byte data is provided in the keychain! In other words, there is no need to calculate the IV at all.

I have an insanely long random master password, so this isn’t a risk for me (it sucks to type on my iPhone), but it’s darn creative and interesting. The folks at AgileBits posted a great response in the comments. Rather than denying the issue, they discussed the risk around it and how they already have an alternative because they recognized issues with their implementation:

I could plead that we were in reasonably good company in making that kind of error, but as I’ve since learned, research in academic cryptography had been telling people not to use unauthenticated encryption for more than a decade. This is why today we aren’t just looking at the kinds of attacks that seem practical, but we are also paying attention to security theorems.

In other words, they owned up and didn’t deny it, which is what we should all do.

For more details, read this deeper response on the AgileBits site. It’s worth it for a sense of these password hashing issues, which are something all security pros need to start absorbing.