[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (OFFICE-2563) NEEDS-DISCUSSION:ODF 1.2 Part 1 CD04: More Digest Algorithms are Wasteful and Burdensome
[ http://tools.oasis-open.org/issues/browse/OFFICE-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18408#action_18408 ]
Dennis Hamilton commented on OFFICE-2563:
-----------------------------------------
[added 2010-04-13] I think the wake-up call on the compromise of the hashes for Apache passwords should be sufficient reason to make clear that so long as the hashes are available in essentially plain sight, the passwords used to set document protections are easily compromised and valuable passwords should never be used for this purpose. Strengthening the hashing is not enough.
In <http://blogs.apache.org/infra/entry/apache_org_04_09_2010> note that
"If you are a user of the Apache hosted JIRA, Bugzilla, or Confluence, a hashed copy of your password has been compromised.
"JIRA and Confluence both use a SHA-512 hash, but without a random salt. We believe the risk to simple passwords based on dictionary words is quite high, and most users should rotate their passwords.
"Bugzilla uses a SHA-256, including a random salt. The risk for most users is low to moderate, since pre-built password dictionaries are not effective, but we recommend users should still remove these passwords from use. "
What they mean is that the hashed copy was disclosed by hackers who were able to extract the information from the Apache site. This was harder to do than getting the hashed protection-key from an ODF document. In addition, two sets of compromised hashes were with SHA-512 but with no salt and users who had any of those are asked to create new passwords (for which the hash will be kept privately).
Note that for the SHA256 ones, presumably the randomly-generated salts were also stolen. Adding a salt would mitigate against one form of attack against table:protection-key, but the salt would be known and dictionary attacks are still possible.
I consider this to be a wake-up call for the use of an unsecured password hashcode retained in ODF documents as a way to set and release protection locks.
> NEEDS-DISCUSSION: ODF 1.2 Part 1 CD04: More Digest Algorithms are Wasteful and Burdensome
> -----------------------------------------------------------------------------------------
>
> Key: OFFICE-2563
> URL: http://tools.oasis-open.org/issues/browse/OFFICE-2563
> Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
> Issue Type: Bug
> Components: Schema and Datatypes, Security
> Affects Versions: ODF 1.2 Part 1 CD 4
> Environment: This issue applies to all forms of ODF 1.2 Part 1 CD04 and to previous version of ODF 1.2 working documents. It does not apply to ODF 1.0 and ODF 1.1.
> Reporter: Dennis Hamilton
> Assignee: Michael Brauer
> Fix For: ODF 1.2 Part 1 CD 5
>
>
> The introduction of table:protection-key-digest-algorithm (19.700) and text:protection-key-digest-algorithm (19.852) opens up the prospect of additional algorithms beside the default SHA1. In fact, SHA256 must be supported by consumers and should be used by producers. The current text also permits SHA512 and RIPEMD-160 by reference to [xmlenc-core]. Additonal algorithms, identified by other URIs, are also allowed.
> This is wasted effort. The digest algorithm does not protect the protection, it only protects the key. Furrthermore, having the hash of the key exposed and available, as it is in the table:protection-key and text:protection-key entries makes it easy to discover the key by well-known password attacks. The only safe key to use in setting protection is one that is worthless for any other purpose and for which its discovery is no loss. In general, hashes should not be used to protect secrets where the hash itself is readily obtained and where the secret is of any serious value. The prospect of possible collisions that have the same hash is in fact uninteresting for this use case.
> By requiring support for stronger digest algorithms in the specification, there is also an unnecessary burden on implementers, conformance assurance efforts, and just plain code bloat for no useful value.
> My preference is that these attributes be removed from the ODF 1.2 specification altogether and that the requirement to use SHA1 be stated as part of the specification for table:protection-key and text:protection-key. That's already more than enough. (XOR folding would probably be sufficient but it is too late for that.).
> Acknowledging that the SHA256 recommendation is likely established in implementations, I propose that only SHA1 and SHA256 be permitted, there be no requirement on producers other than they use one, and no other digest algorithms be allowed or expected.
--
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]