[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (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:comment-tabpanel&focusedCommentId=30754#action_30754 ]
Dennis Hamilton commented on OFFICE-3703:
-----------------------------------------
CONSTRAINTS ON ADDITION OF PROTECTION-KEY CASES
I wanted to point out a design factor for the Protection-Key enhancements as they are proposed.
There are only two attributes wherever a protection-key setting is provided.
The first attribute is one of table:protection-key or text:protection-key, with the different names used at different places in the schema. This attribute is the only one whose value can contain the key information. That is, any salt, any count, any digest value, any other parameters that are public and required to authenticate the protection-key in accordance with the digest method.
The other attribute is the optional table:protection-key-digest-algorithm and text:protection-key-digest-algorithm. For enhancements, the values are URIs that are understood as identifiers of specific methods that determine how the associated protection-key attribute value is to be used for authenticating an user request to unlock the protection.
In the default case, and in the explcit SHA1 case, the protection-key value is expressed with a base64Binary representation of a 160-bit (20 byte) hash value. Because an SHA1 hash tends to be indisctinguishable from a random 160-bit value, other indistinguishable from-hash values can be substituted with no harm, although there might be no password whose SHA1 has matches. That is the principle behind the AUTHZ160 method that is proposed to replace the default. Although it is not required to have detectable structure, it suffices to avoid being a password-compromising digest value.
In the explicit SHA1DK case, the protection-key attributes encodes a 320-bit value which, with the exception of the first 8 bits, is strongly indistinguishable from a random sequence of bits. In addition, the first 160 bits fail to succeed as a password-compromising digest value. The first 8 bits are a code that determines the number of iterations that will be used in performing a salted digest iteration. The first 160 bits are used, despite the non-random character of the first 8 bits, as the salt that is used, along with a password, to produce the last 160 bits, a derived key that is effectively an irreversible function of the first 160 bits and the user-supplied password.
This use of the protection-key attribute to pack all of the parameters and any authentication value (also known as a tag) applies for additional methods that might be introduced for interoperability purposes. The protection-key-digest-algorithm attribute would carry a unique identifier that distinguished the method for each case. For example, to derive a table:protection-key value from a Microsoft Excel spreadsheet, there would need to be combination of a salt and a digest and the method would distinguish what the algorithm is and what the encoding of the password is (when not UTF-8). In the case of variable character-set encodings, that might need to be conveyed in the structure of the protection-key value also. Even if a consumer did not support the necessary authentication procedure, it could preserve the lock and also properly transform the settings to the form required on export of the document back to Microsoft Excel format.
> 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]