On 03/26/2012 09:00 AM, C. Michael Pilato wrote: > The on-disk cache will contain everything it does today where > plaintext caching is enabled, save that the password won't be > plaintext, and there will be a bit of known encrypted text (for > passphrase validation).
Is it important to be able to locally validate the passphrase? That property intrinsically enables offline dictionary attacks. > We'd need to pull in additional dependencies that have freely > available implementations on all our supported platforms. > Blowfish, 3DES, or somesuch. Unfortunately, there's more complexity in an encrypted password store than you probably anticipated, and it's definitely possible to lose some or most of your intended security properties if you get it wrong. The choice of best cipher algorithm today is very simple (AES, although you'll have to pick the key size from 128/196/256 bits), but you do need to decide whether you want to be cipher-agile. Basically, if AES becomes a weak choice down the road (and it probably will, though it could be decades), is it better to be able to swap out the algorithm inside the password storage system, or better to just plan to swap out the system entirely for a redesigned one? Either position is defensible. You'll need to pick a function to map a passphrase to a crypto key. If you do a bad job, it will become easier to brute-force search for keys because your key distribution won't be even. To ensure even distribution, you typically need to use a hash function, which is an added dependency. String-to-key functions are also often deliberately slow, to make offline dictionary attacks harder. PBKDF2 (RFC 2898) is a reasonable choice here, and is implemented in some crypto libraries. You'll need to pick an appropriate cipher mode. If you simply use ECB (where you chunk the plaintext up into blocks and encrypt each block with the key), it will become easy to tell which passwords, or parts of passwords, are the same as which others. Maybe not a critical flaw, but certainly an avoidable one. If you use CTR (where you encrypt counter values with the key and XOR the result with the password), you'll need to make sure that counter values are never reused, or it will become easy to recover passwords with the key. CBC with a random initialization vector is also an option. If you don't use CTR mode, you'll need to pick a reversible padding function for the plaintext so that it matches a multiple of the cipher's block size. This is pretty simple. It's probably wise to look at what another implementation does. I'm not sure what password store implementations have made obvious mistakes and which ones haven't; I wish I had a better reference to give, but I don't know the state of the art for this particular application of crypto as well as others.