8.5.1 - exposed passwords are a security risk

["David A. Wheeler" <dwheeler@dwheeler.com>]

Section 8.5.1 defines a "protection-key" to prevent editing.

In the large this provides very little protection; someone
could just edit the data file directly.  Indeed, this is
problem for all "locked" formats (like PDF "no print" etc.)
options where the data is indeed still there.
However, as an advisory to prevent naive users from editing
the material, this makes some sense, as long as they don't look
for alternatives.

But there's much larger problem: the password here is
exposed to anyone who unzips the file!! NEVER store
passwords "in the clear", because users tend to use the
same passwords in multiple situations.  Instead, use
salt and a hashing algorithm, so that programs can
check to see if the password matches, without revealing
the password itself.

A simple approach is to use the GNU extensions to crypt(3),
which are nice and extensible:
        The glibc2 version of this function has the following  additional  fea-
        tures.   If  salt is a character string starting with the three charac-
        ters "$1$" followed by at most eight characters, and optionally  termi-
        nated  by  "$",  then instead of using the DES machine, the glibc crypt
        function uses an MD5-based algorithm,  and  outputs  up  to  34  bytes,
        namely  "$1$<string>$", where "<string>" stands for the up to 8 charac-
        ters following "$1$" in the salt, followed by 22 bytes chosen from  the
        set [a–zA–Z0–9./].  The entire key is significant here (instead of only
        the first 8 bytes).

It'd be stronger if you used another prefix ($2$ or $3$), and used
SHA-1 or HMAC-SHA-1 as the hash algorithm. But don't store any
passwords in the clear.

Do the same thing anywhere else there's a password-based protection
algorithm.

--- David A. Wheeler