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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] Commented: (OFFICE-2562) ODF 1.2 Part 1 CD04:protection-key password format unspecified

    [ http://tools.oasis-open.org/issues/browse/OFFICE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18544#action_18544 ] 

Dennis Hamilton commented on OFFICE-2562:

I think what the feature does is protect table cells and text against accidental alteration.  In the case of table:protection-key, the only one I have found to be implemented in OO.o, the feature protects table cells from inadvertent alteration of formulas or fixed values.  (Recalculation and calculation on loading is not prevented, but formulas on protected cells cannot be changed and, protected cells having no formula cannot be altered.  I wondered about that.  It seems like the right way to have it work and it does in all spreadsheet programs I tried it on.)

As we know, the protection does not extend to intentional circumvention, which is relatively easy.

Because the convention is that setting and relaxation of protection is by use of a plaintext password, we are in the funny business of needing to provide security for the password, not because it matters for circumvention of the protection, but because it matters in case the password is itself valuable.

The problem, of course, is using an unsalted digest of a valuable secret and then not protecting the digest value is completely inadequate as  security measure and having the hash makes it relatively easy to attack the password, especially if it is memorable and used in many different ways as a convenience of the password creator.  

OFFICE-2563 is about this conflict of interests and how to deal with the fact that there are not only warnings against this practice but that we have this very week learned of a major exploit with regard to the theft of password hash values that are vulnerable in exactly this way.

WITH REGARD TO THE CURRENT ISSUE: I trust it is clear that the proposal is not serious.  We need to decide on reasonable character set limitations for purposes of interoperability, and there should be some fixed length beyond which password text is ignored if not prohibited.  If, on the other hand, we do not believe there is an interoperability use case and the password is meant only for use by the originator of the document using the same software, the proposal is good enough.

> ODF 1.2 Part 1 CD04: protection-key password format unspecified
> ---------------------------------------------------------------
>                 Key: OFFICE-2562
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2562
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Security, Table, Text
>    Affects Versions: ODF 1.2 Part 1 CD 4 
>         Environment: This issue applies to all versions of ODF 1.2 Part 1 CD04, earlier drafts, and to ODF 1.1 and ODF 1.0
>            Reporter: Dennis Hamilton
>             Fix For: ODF 1.2
> The table:protection-key (19.699) and text:protection-key (19.852) attributes carry the results of hashing of sequences of binary bits supplied to a digest algorithm.  The input is internal computer data.
> For ODF 1.2 Part 1 protection-key attributes, it is not specified how those binary bits are obtained nor how a consumer of a document holding such keys is expected to obtain the same binary bits and confirm their submission by arriving at the same hash-code result.
> This proposal establishes that UTF-8 encoding in binary octets shall be used.
> This proposal establishes that the permissible Unicode characters shall be the same ones permitted for encoding of XML document in Unicode.
> Finally, truncation or limitation of the string differently by the consumer than is applied by the producer requires that there be some agreement on where truncation shall occur.  The value of 2^61-1 octets is chosen because that is the limitation on the input for SHA1.    It would be wise to find a more-practical though generous limitation.  This proposal makes no recommendation.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]