[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 8.5.1 - exposed passwords are a security risk
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]