[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (OFFICE-3703) Proposal: ODF 1.3 Protection-Key Enhancements
[ http://tools.oasis-open.org/issues/browse/OFFICE-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Hamilton updated OFFICE-3703:
------------------------------------
Proposal:
[Updated 2012-06-12]
Version 1.05 of the full proposal with explanatory support is provided at http://www.oasis-open.org/committees/document.php?document_id=46218 , 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
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
[Errata-style instructions for modifying the text of ODF 1.2 for transposition into ODF 1.3]
3. DEPLOYMENT CONSIDERATIONS
3.1 Down-Level Considerations
3.2 Immediate Usabilty 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
Two new protection-key-digest-algorithm URIs are proposed. One for SHA1DK using a 20-byte salt iteratively in deriving a protection key, the other for AUTHZ160 with an 20-byte binary protection-key that is not dependent on a password and cannot be subjected to brute-force attack to obtain a password.
was:
[Updated 2012-06-12]
Version 1.05 of the full proposal with explanatory support is provided at http://www.oasis-open.org/committees/document.php?document_id=46218 , 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
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
[Errata-style instructions for modifying the text of ODF 1.2 for transposition into ODF 1.3]
3. DEPLOYMENT CONSIDERATIONS
3.1 Down-Level Considerations
3.2 Immediate Usabilty 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
Two new protection-key-digest-algorithm URIs are proposed. One for sha1-salt with a minimum 20 byte salt, one for authz160 with a minimum 20-byte binary protection-key that is not dependent on a password and cannot be subjected to brute-force attack to obtain a password.
[I corrected an out-of-date paragraph at the end of the Proposal statement].
With regard to the reference to SHA1DKX, that method is not paritcularly useful over SHA1DK in the case of ODF documents. It could be used, but the additional parameter that SHA1DKX uses cannot be a secret so it might as well not be used.
Here's more:
Although SHA1DKX, the contextual customization of SHA1DK, is not needed for
ODF protection keys, it is useable in implementation of a tear-off, off-line
authentication of AUTHZ160 randomly-generated protection keys. That has uses
beyond ODF too.
Using the notation in the Protection-Key Enhancements v1.05 document, here is
SHA1DKX:
dk = SHA1DKX(password, salt, context)
= PBKDF2(PRF, SHA1(password)||context, salt, c, dkLen)
and SHA1DK is SHA1DKX with NULL (0-length) context.
The context is preferably binary with low redundancy, it could be a digital
hash, it can be (but need not be) secret, and the result
SHA2(password)||context should not exceed 55 octets (to fit inside a single
SHA1 block for the HMAC-SHA-1 used in PBKDF2).
(The use of SHA1(password) is so that this can be used in rekeying existing
SHA1-digest password values without requiring the password. I have to keep
reminding myself that this is not a weakness since an attack on SHA1(password) is not much different than an attack on password and that is, as always, more a function of password weakness than anything else.)
> Proposal: ODF 1.3 Protection-Key Enhancements
> ---------------------------------------------
>
> Key: OFFICE-3703
> URL: http://tools.oasis-open.org/issues/browse/OFFICE-3703
> Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
> Issue Type: Improvement
> Components: Security, Table, Text
> Affects Versions: ODF 1.0, ODF 1.0 (second edition), ODF 1.1, ODF 1.2, ODF 1.2 COS 1
> Environment: This is an enhancement, described in terms of changes to OpenDocument-v1.2-os.
> Reporter: Dennis Hamilton
> Assignee: Dennis Hamilton
> Fix For: ODF 1.3, ODF 1.3 CSD 01
>
>
> 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. Recent (June 2012) reveal that 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. And 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 alone. SHA1DK uses an AUTHZ160-sized cryptographically-random salt and an iterative key derivation procedure that makes discovery of a password by repeated trials very costly. (SHA1DK and an extension, SHA1DKX, can be used to create tear-off secret authenticators for AUTHZ160 protection keys, even though a protection-key that includes all of the SHA1DK result is password based.)
--
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]