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-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:comment-tabpanel&focusedCommentId=18790#action_18790 ] 

Dennis Hamilton commented on OFFICE-2639:

Michael, I think the changes I already specified do everything you say (and remove statements made in other places that *:protection-key is a hashed password copy.

I think your proposed language is fine for the parts you mention is fine.  I would adjust the English for table:protection:

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

I think it is better to say that

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.

For the last change, "not based on passwords" is probably too strong.  We just don't want the authorization procedure to ever see a password or, if they are seen, not have them be retained in any form in the document.  I suggest  "not based on storing passwords in any form, including hash-coded copies."

[PS: There are a number of ways to accomplish this by a supplemental agreement and registration of a URI.  I didn't want to have that be on the ODF 1.2 critical path.  It is an interesting topic to take up separately.]

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