Re: [office-comment] 8.5.1 - exposed passwords are a security risk

[Michael Brauer <Michael.Brauer@Sun.COM>]

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
>