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.
Received on 2012-03-26 17:46:06 CEST