[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-comment] 8.5.1 - exposed passwords are a security risk
David, actually the intention is that applications never save the password as plain text, but alaways a hash value of the password. While the decription of the text:protection-key attribute for text sections (<text:section> element) contains this information, we have overseen to add it to the table:protection-key attribute for tables. Thank you very much for alerting us about this. Best regards Michael Brauer OASIS Open Office TC chair David A. Wheeler wrote: > 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]