Details

    • Type: Bug Bug
    • Status: Applied
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: ODF 1.2 Part 1 CD 4
    • Fix Version/s: ODF 1.2 Part 1 CD 5
    • Labels:
      None
    • 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.
    • Proposal:
      Hide
      In the ODF 1.2 Part 1 schema for attributes table:protection-key-digest-algorithm and text:protection-key-digest-algorith, specify the exact values that are permitted as constraints on the anyURI type:

        http://www.w3.org/2000/09/xmldsig#sha1
        http://www.w3.org/2000/09/xmldsig#sha256

      In the text for each of section 19.700 table:protection-key-digest-algorithm and section 19.853 text:protection-key-digest-algorithm, replace all of the first paragraph after the first sentence with the following text:

      """
      It takes the values that identify SHA1 and SHA256 in §5.7 of [xmlenc-core]. Consumers shall support both SHA1, the default, and SHA256.
      """
      Show
      In the ODF 1.2 Part 1 schema for attributes table:protection-key-digest-algorithm and text:protection-key-digest-algorith, specify the exact values that are permitted as constraints on the anyURI type:    http://www.w3.org/2000/09/xmldsig#sha1    http://www.w3.org/2000/09/xmldsig#sha256 In the text for each of section 19.700 table:protection-key-digest-algorithm and section 19.853 text:protection-key-digest-algorithm, replace all of the first paragraph after the first sentence with the following text: """ It takes the values that identify SHA1 and SHA256 in §5.7 of [xmlenc-core]. Consumers shall support both SHA1, the default, and SHA256. """
    • Resolution:
      No action

      Description

      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.

        Activity

        Hide
        Dennis Hamilton (Inactive) added a comment -
        For external discussion of how stronger hashing is not the issue, and revealing the hashcode helps attackers, there is this passage in the Wikipedia discussion of SHA hash functions, http://en.wikipedia.org/w/index.php?title=SHA_hash_functions&oldid=345184306

        "Some of the applications that use cryptographic hashes, such as password storage, are only minimally affected by a collision attack. Constructing a password that works for a given account requires a preimage attack, as well as access to the hash of the original password (typically in the shadow file) which may or may not be trivial [though it is when the hash is in an XML document]. Reversing password encryption (e.g. to obtain a password to try against a user's account elsewhere) is not made possible by the attacks [using a collision]. (However, even a secure password hash can't prevent brute-force attacks on weak passwords.)" [insersions are mine: dh]

        For a general discussion of why secrets shouldn't be hashed, there is a 2008 post from Ben Adita, "Don't Hash Secrets" at http://benlog.com/articles/2008/06/19/dont-hash-secrets/ and I have a lengthy analysis of my own at http://orcmid.com/blog/2010/02/document-security-theater-when-key-is.asp

        Concerning how wasteful it is to expand the set of authorized digest algorithms, think about the added complexity of conformance testing, interoperability confirmation, and many other increases in effort and cost among adopters as well as producers of compliant products. It is all waste relative to the presumed increase in safety involving a feature that has no security value in the first place.
        Show
        Dennis Hamilton (Inactive) added a comment - For external discussion of how stronger hashing is not the issue, and revealing the hashcode helps attackers, there is this passage in the Wikipedia discussion of SHA hash functions, http://en.wikipedia.org/w/index.php?title=SHA_hash_functions&oldid=345184306 "Some of the applications that use cryptographic hashes, such as password storage, are only minimally affected by a collision attack. Constructing a password that works for a given account requires a preimage attack, as well as access to the hash of the original password (typically in the shadow file) which may or may not be trivial [though it is when the hash is in an XML document]. Reversing password encryption (e.g. to obtain a password to try against a user's account elsewhere) is not made possible by the attacks [using a collision]. (However, even a secure password hash can't prevent brute-force attacks on weak passwords.)" [insersions are mine: dh] For a general discussion of why secrets shouldn't be hashed, there is a 2008 post from Ben Adita, "Don't Hash Secrets" at http://benlog.com/articles/2008/06/19/dont-hash-secrets/ and I have a lengthy analysis of my own at http://orcmid.com/blog/2010/02/document-security-theater-when-key-is.asp Concerning how wasteful it is to expand the set of authorized digest algorithms, think about the added complexity of conformance testing, interoperability confirmation, and many other increases in effort and cost among adopters as well as producers of compliant products. It is all waste relative to the presumed increase in safety involving a feature that has no security value in the first place.
        Hide
        Dennis Hamilton (Inactive) added a comment -
        [Added Schema to the components]

        MORE ABOUT THE SCHEMA

        In the CD04 Schema, the paired protection-key and protection-key-digest-algorithm attributes are *independently* optional. Rather than have to deal with interoperability and/or additional specification complication on dealing with a protection-key-digest-algorithm when there is no protection-key, I request that the schemas be modified so that the protection-key-digest-algorithm is allowd and optional only when the corresponding protection-key attribute is present.
        Show
        Dennis Hamilton (Inactive) added a comment - [Added Schema to the components] MORE ABOUT THE SCHEMA In the CD04 Schema, the paired protection-key and protection-key-digest-algorithm attributes are *independently* optional. Rather than have to deal with interoperability and/or additional specification complication on dealing with a protection-key-digest-algorithm when there is no protection-key, I request that the schemas be modified so that the protection-key-digest-algorithm is allowd and optional only when the corresponding protection-key attribute is present.
        Hide
        Michael Brauer (Inactive) added a comment -
        Regarding the has value algorithms: The justification for stronger algorithms than SHA1 is that many users use the same passwords for multiple tasks. So, it is worth to protect the key. Since we explicitly added the attributes to ODF 1.2 on request, we should not revert this.

        Regarding the schema. Your request is valid. I will adapt the schema.
        Show
        Michael Brauer (Inactive) added a comment - Regarding the has value algorithms: The justification for stronger algorithms than SHA1 is that many users use the same passwords for multiple tasks. So, it is worth to protect the key. Since we explicitly added the attributes to ODF 1.2 on request, we should not revert this. Regarding the schema. Your request is valid. I will adapt the schema.
        Hide
        Dennis Hamilton (Inactive) added a comment -
        The problem for using the same password for multiple purposes is that it is so easy to attack the password used for table:protection-key and discover what that password is. If that password is also for a more-valuable purpose, that purpose is now exposed to a security threat by this avenue. (I also suspect that, by their nature, the same key used for multiple purposes is extremely likely to be discoverable in a plain-text attack on the protection-key digest value, no matter how we think we have "strengthened" its protection with stronger digest algorithms.

        Users ask for lots of things. It is not clear that this device in this situation actually satisfies the user concerns. I am concerned that we are participating in a deception.
        Show
        Dennis Hamilton (Inactive) added a comment - The problem for using the same password for multiple purposes is that it is so easy to attack the password used for table:protection-key and discover what that password is. If that password is also for a more-valuable purpose, that purpose is now exposed to a security threat by this avenue. (I also suspect that, by their nature, the same key used for multiple purposes is extremely likely to be discoverable in a plain-text attack on the protection-key digest value, no matter how we think we have "strengthened" its protection with stronger digest algorithms. Users ask for lots of things. It is not clear that this device in this situation actually satisfies the user concerns. I am concerned that we are participating in a deception.
        Hide
        Dennis Hamilton (Inactive) added a comment -
        I request a TC discussion on this issue.
        Show
        Dennis Hamilton (Inactive) added a comment - I request a TC discussion on this issue.
        Hide
        Dennis Hamilton (Inactive) added a comment -
        [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.
        Show
        Dennis Hamilton (Inactive) added a comment - [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.
        Hide
        Dennis Hamilton (Inactive) added a comment - - edited
        This has been superseded by a later issue, OFFICE-2639
        Show
        Dennis Hamilton (Inactive) added a comment - - edited This has been superseded by a later issue, OFFICE-2639

          People

          • Assignee:
            Michael Brauer (Inactive)
            Reporter:
            Dennis Hamilton (Inactive)
          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: