[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (OFFICE-2639) NEEDS-DISCUSSION:Prepare Deprection of Visible Hashed Copies of Passwords
[ http://tools.oasis-open.org/issues/browse/OFFICE-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Brauer updated OFFICE-2639:
-----------------------------------
Resolution:
Adapt 19.698.4 <table:table>/table:protected:
Adapt 2nd sentence from
If the table is protected and the table:protection-key attribute is present, an authorization is required for resetting the protection flag to enable editing.
to
If the table is protected, the table:protection-key attribute can specify an authorization requirement for resetting the protection flag to enable editing.
19.699 table:protection-key: Adapt description to.
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 19.700. The attribute value is binary data that may be used by the authentication procedure.
19.700 protection-key-digest-algorithm: Replace first paragraph with:
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 storing passwords in any form, including hash-coded copies.
19.797 table:structure-protected. Replace first paragraph with:
The table:structure-protected attribute specifies whether a table is protected from the insertion, deletion, moving or renaming of tables in the document. If the table structure is protected and the table:protection-key attribute is present, an authorization is required for resetting the protection flag to enable editing.
19.851 text:protected Replace the note with
If the section is protected and the text:protection-key attribute is present, an authorization is required for resetting the protection flag to enable editing.
19:852 text:protection-key Adapt description to.
The text:protection-key attribute, when present, specifies that an authorization is required for removing the protection of a section. The authentication procedure is identified by the text:protection-key-digest-algorithm attribute 19.852. The attribute value is binary data that may be used by the authentication procedure.
19.852 text:protection-key-digest-algorithm Replace first paragraph with:
The text: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 text: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 text: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 storing passwords in any form, including hash-coded copies.
was:
Adapt 19.698.4 <table:table>/table:protected:
Adapt 2nd sentence from
If the table is protected and the table:protection-key attribute is present, an authorization is required for resetting the protection flag to enable editing.
to
If the table is protected, the table:protection-key attribute can specify an authorization requirement for resetting the protection flag to enable editing.
19.699 table:protection-key: Adapt description to.
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 19.700. The attribute value is binary that may be used by the authentication procedure.
19.700 protection-key-digest-algorithm: Replace first paragraph with:
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.
I've adapted the proposal as suggested by Dennis and extended it to the other attributes. The current proposal/resolution can be found in the resolution field.
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]