Sunday, March 25, 2007
Cohen on Howard: Chapter 9
Chapter 9 deals with encryption and protecting secret data.
Cohen largely approves of Chapter 9. In particular, he likes the fact that the authors state knowledge of cryptography and mathematics is not sufficient: you must apply it in a way that makes sense. (For a way that doesn't make sense, see the picture to the right.)
Howard:
Cohen:
Yes -- if you add CPU, user and I/O time it will come close to 100%. However, the authors make it clear that they concatenate the values rather than sum then. Even so, due to issues with representing numbers in computer systems, CPU + user + I/O time may not always sum to 100 depending on Microsoft's internal representation.
Cohen:
Cohen does not indicate which Microsoft product is storing passwords unsalted. Doubtless, many earlier Microsoft products had this problem before it was well understood to be a problem. Indeed -- many Linux distributions of a bygone time didn't shadow their passwd files, even though /etc/passwd was world-readable and had a small saltspace. Even today, Wordpress doesn't salt user passwords -- and uses the insecure MD5 hash to boot!
Cohen largely approves of Chapter 9. In particular, he likes the fact that the authors state knowledge of cryptography and mathematics is not sufficient: you must apply it in a way that makes sense. (For a way that doesn't make sense, see the picture to the right.)Howard:
CryptGenRandom gets its randomness, also known as system entropy, from many sources in Windows 2000 and later, including the following: [...lists on the order of 100 counters...]
The resulting byte stream is hashed with SHA-1 to produce a 20-byte seed value that is used to generate random numbers according to FIPS 186-2 appendix 3.1.
Cohen:
The authors rightly spend a substantial amount of time on generating decent pseudo-random numbers [...] Of course their solution is a Microsoft system call that they assert does it right. I should note that the parameters they claim to use to generate their random seeds contain some very predictable values and sets of values that, while individually may not be very predictable may be more predictable together. For example, when we add the CPU, User, and I/O time it may come to a predictable value (100%) even if each is not very predictable on their own.
Yes -- if you add CPU, user and I/O time it will come close to 100%. However, the authors make it clear that they concatenate the values rather than sum then. Even so, due to issues with representing numbers in computer systems, CPU + user + I/O time may not always sum to 100 depending on Microsoft's internal representation.
Cohen:
They do tell us to use salts for hash functions to store things like passwords. Their inability to get the job done at Microsoft shines through when we realize that the password scheme used in Microsoft products didn't use salts for their hashes and resulted in a widely published dictionary-based attack based on this weakness. It saddens me to see that even when the authors get it right the company gets it wrong.
Cohen does not indicate which Microsoft product is storing passwords unsalted. Doubtless, many earlier Microsoft products had this problem before it was well understood to be a problem. Indeed -- many Linux distributions of a bygone time didn't shadow their passwd files, even though /etc/passwd was world-readable and had a small saltspace. Even today, Wordpress doesn't salt user passwords -- and uses the insecure MD5 hash to boot!
