[OASIS Issue Tracker] Commented: (OFFICE-2639) NEEDS-DISCUSSION:Prepare Deprection of Visible Hashed Copies of Passwords

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Michael Brauer commented on OFFICE-2639:
----------------------------------------

A couple of comments:

1) I have no objections to adding the possibility to use other authorization methods than hashed passwords, but we should make clear that if hash algorithms are specified, that these then should be applied to passwords.

2)We should be careful to not make the password protection a mandatory feature, in particular since we all know that it is not really a security feature (BTW: I have used that component to get the issue to the attention of our security experts). The proposal for 19.6.8.4 currently does that.

3)We should preserve what is currently said about what is protected.


So, what about something like this (for the table attributes; the text attributes would be adapted the same way)

table:protection:

If the table is protected, the table:protection-key attribute specifies an authorization requirement for resetting the protection flag to enable editing. 

table:protection-key:

The table:protection-key attribute, when present, specifies that an authorization is required for removing the protection of a table, table cell or scenario. The authentication procedure is identified by the table:protection-key-digest-algorithm attribute. The attribute value is binary that may be used by the authentication procedure.

protection-key-digest-algorithm:

The table:protection-key-digest-algorithm attribute value is an IRI that identifies an authentication procedure for removing a protection.

If the IRI identifies a message-digest algorithm specified in §5.7 of [xmlenc-core], the value of table:protection-key attribute  shall be the hash value of the password that is required to authorize removal of the protection. The password shall be provided as a sequence of bytes in UTF-8 encoding. 

Any other procedures, their identifying IRIs, and their application of table:protection-key values are implementation-defined.

Consumers shall support http://www.w3.org/2000/09/xmldsig#sha1, which is the default, and http://www.w3.org/2000/09/xmldsig#sha256. They may support other algorithms described in §5.7 of [xmlenc-core] or alternative procedures. Producers should use http://www.w3.org/2000/09/xmldsig#sha256, or an alternative procedure that is not based on passwords.


> NEEDS-DISCUSSION: Prepare Deprection of Visible Hashed Copies of Passwords
> --------------------------------------------------------------------------
>
>                 Key: OFFICE-2639
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2639
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Security, Table, Text
>    Affects Versions: ODF 1.0, ODF 1.0 (second edition), ODF 1.1, ODF 1.2, ODF 1.2 Part 1 CD 4 
>         Environment: use of *:protection-key attributes in all applications of OpenDocument text and spreadsheet documents.
>            Reporter: Dennis Hamilton
>            Priority: Blocker
>             Fix For: ODF 1.2 Part 1 CD 5
>
>
> Since ODF 1.0, there is a security vulnerability in the use of hashed copies of passwords as values of *:protection-key attributes.  Having the hashed password copies retrievable from the document permits discovery of the password and attack on other uses of it.
> Although a number of cases are already implemented, using SHA-1 and apparently SHA-256, it is proposed to prepare for deprecation of  *:protection-key usages where the value of the attribute is a directly-derived as a hash-coded copy of a potentially-memorable/-reusable password.
> No safe algorithm is proposed, since there is no known-safe implementation currently in use.  Such implementations are known to be possible, however.
> To make room for introduction of safe algorithms that do not depend on the OpenDocument producer and consumer ever receiving an user secret in any form recoverable or verifiable from the document, this proposal simply restates the current provisions so that non-hashed-password methods can be introduced without expanding the number of attributes or interfereing with current implementations.
> In order to accomplish this, the repetitious restatements of how *:protection-key works are also removed from all places except where that attribute and *:protection-key-digest-algorithm are defined directly.
> NOTE 1: These changes impact and supersede the Issues OFFICE-2561, OFFICE-2562, and OFFICE-2563
> NOTE 2: These changes are solely for allowing remedy to the use of hashed copies of passwords.  No effort is made to resolve other questions that might apply in how protections work and are specified.

-- 
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