OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[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


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]