|
[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. 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. 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. I request a TC discussion on this issue.
[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. This has been superseded by a later issue,
|
||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Applied
Major
ODF 1.2 Part 1 CD04: More Digest Algorithms are Wasteful and Burdensome
"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.