[OFFICE-3703] Proposal: ODF 1.3 Protection-Key Enhancements - OASIS Technical Committees Issue Tracker

Details

Type: Improvement
Status: New
Priority: Major
Resolution: Unresolved
Affects Version/s: ODF 1.0, ODF 1.0 (second edition), ODF 1.1, ODF 1.2, ODF 1.2 COS 1
Fix Version/s: ODF-Later
Component/s: Security, Table, Text
Labels:
None
Environment:

This is an enhancement, described in terms of changes to OpenDocument-v1.2-os.

Proposal:

Hide

[Updated 2013-05-02]

Version 1.06 of the full proposal with explanatory support is provided at https://www.oasis-open.org/committees/document.php?document_id=49071 , with specification of explicit changes to the text of these sections of ODF 1.2 for incorporation in ODF 1.3.

There is related analysis considering the safe use of protection keys in ODF documents in draft advisory #00009 of the OIC TC, located at https://tools.oasis-open.org/version-control/svn/oic/Advisories/00009-ProtectionKeySafety/trunk/description.html

v1.06 is an editorial improvement of v1.05, with important modifications to
SHA1DK. The two new protection-key methods are still proposed to replace
the current default and alternatives, with the explicitly-named ODF 1.2
alternatives identified as deprecated and not to be produced in ODF 1.3
documents.

AUTHZ160 does not depend on a hashing algorithm to match is value in order
to authenticate removal of a protection.

SHA1DK is password based but it uses salt values and iterated hashing to
make it far more costly to attempt to discover the password used by
repeated trials. Passwords that are used should still be considered
compromised simply because the protection key, even though 320 bits, is
still available in plain sight and subject to off-line attacks.

1. Rationale
1.1 Vulnerability of Password Hash Values
1.2 SHA1DK for Password-Based Protection-Key Values
1.3 AUTHZ160 for Password-Less Protection-Key Values

2. Proposed Changes

3. Deployment Considerations
3.1 Down-Level Considerations
3.2 Immediate Usability of AUTHZ160 for Default Protection
Keys
3.3 Confirmation of Resilient Down-Level Treatment
3.4 Future-Proofing of Extended ODF 1.2 Consumers and
Producers

[Note: In section 2, the separation of the iteration count from the
cryptographically-random salt portion is made explicit. It is now possible
to produce the count as the result of iterative hashing under a time
constraint.]

Show
[Updated 2013-05-02] Version 1.06 of the full proposal with explanatory support is provided at https://www.oasis-open.org/committees/document.php?document_id=49071 , with specification of explicit changes to the text of these sections of ODF 1.2 for incorporation in ODF 1.3. There is related analysis considering the safe use of protection keys in ODF documents in draft advisory #00009 of the OIC TC, located at https://tools.oasis-open.org/version-control/svn/oic/Advisories/00009-ProtectionKeySafety/trunk/description.html v1.06 is an editorial improvement of v1.05, with important modifications to SHA1DK. The two new protection-key methods are still proposed to replace the current default and alternatives, with the explicitly-named ODF 1.2 alternatives identified as deprecated and not to be produced in ODF 1.3 documents. AUTHZ160 does not depend on a hashing algorithm to match is value in order to authenticate removal of a protection. SHA1DK is password based but it uses salt values and iterated hashing to make it far more costly to attempt to discover the password used by repeated trials. Passwords that are used should still be considered compromised simply because the protection key, even though 320 bits, is still available in plain sight and subject to off-line attacks. 1. Rationale 1.1 Vulnerability of Password Hash Values 1.2 SHA1DK for Password-Based Protection-Key Values 1.3 AUTHZ160 for Password-Less Protection-Key Values 2. Proposed Changes 3. Deployment Considerations 3.1 Down-Level Considerations 3.2 Immediate Usability of AUTHZ160 for Default Protection Keys 3.3 Confirmation of Resilient Down-Level Treatment 3.4 Future-Proofing of Extended ODF 1.2 Consumers and Producers [Note: In section 2, the separation of the iteration count from the cryptographically-random salt portion is made explicit. It is now possible to produce the count as the result of iterative hashing under a time constraint.]

Description

The use of password hashes in easily-discovered XML element and attribute values is subject to compromise of the hashed password. Although the use of increasingly-stronger digest algorithms may lengthen the time required for carrying out a brute-force attack on the hash, memorable passwords remain subject to compromise and the attack becomes easier as processor technology advances. Currently (May 2013) there is an explosive growth in hacks involving the discovery of passwords that are authenticated by use of unsalted digest algorithms.

In addition, the presence of hashes in plain sight in XML documents allows the digest value to be easily compared with the same digest value elsewhere, revealing worthy targets to an adversary. In addition, the digest value is easily removed/replaced. An extracted digest value can be repurposed for malicious purposes.

This proposal introduces two protection-key digest algorithms, AUTHZ160 and SHA1DK that are intended to mitigate risks associated with use of digest algorithms and provision of the digests in plain view in XML documents. AUTHZ160, the recommended new default, uses protection-keys that are not derived from a password at all. They are 100% protection against discovery of an actual password known to the user by analysis of the protection key. SHA1DK uses a cryptographically-random salt and an iterative key derivation procedure that makes discovery of a password by repeated trials very costly.

Proposal: ODF 1.3 Protection-Key Enhancements

Details

Description

Attachments

Activity

People

Dates