The problem here is the key derivation function. There are two factors that most significantly affect the efficiency of recovering a password from a derived key:
1) The number of operations needed to derive the key
2) Whether a _random_ salt has been used, and the number of bits present in the salt
The salt protects against what is known as a rainbow table attack. If no salt is present, then one rainbow table can be used to brute force all the passwords very quickly. As the number of bits grows, so does the number of rainbow tables needed to make the attack. This is why Microsoft Office uses 16 bytes of salt for password verifiers, and derives the salt completely randomly, using a verified source of randomness. I don't recall whether this is still present in the ODF spec, but there was a clause that said the random number generator should be initialized with the time - that's incorrect, as the time can be guessed, and that actually hurts the overall randomness. All we should specify is that there should be some number of bytes of random data. How to get random data is up to the implementation, and is highly platform-dependent.
The number of repeated hashes should also be very high - Microsoft Office currently use 100,000 iterations. This yields < 10,000 crack/second, even when attacked by a GPU. A well-chosen password can stand up to this number of cracks (assuming that a very large botnet isn't also used) for long enough that the password won't have value when obtained.
Any time you want to store a password verifier, for example to be used with sheet protection, write protection, etc, PBKDF2 should be used with a good hash, a large iteration count, and a large, random salt.
Not using salt is what leads to the attacks listed in the URL below.
________________________________________
From: Dennis E. Hamilton [dennis.hamilton@acm.org]
Sent: Saturday, October 30, 2010 11:48 AM
To: ODF TC List
Subject: [office] The problem of visible hashes for protection keys
We know that, using XML documents, it is easy to subvert a lock on text or
spreadsheet documents that involves locking material against changes (but
not reading). When the lock is itself locked against removal using a
password hash, this exposes the password used for the hash to compromise.
The problem is the desire by folks to reuse familiar, memorable passwords
for this purpose when the memorable password is also used to protect
something that is of serious high value. (That is to say, the password is
more valuable than the trivial-to-break lock in the document.)
Some bad news:
<
http://www.ciozone.com/index.php/Security/Cracking-14-Character-Complex-Pass
words-in-5-Seconds.html>
Note that memorable passwords are not the hard ones to crack, and increasing
the strength of the hash will not do much to protect memorable passwords
from discovery against this kind of computational power.
Note: This attack does not work against the PBKDF2 methods used for ODF 1.2
encryption, because the start password is never revealed. On the other
hand, the techniques by which the password-hash attack were accelerated so
much is probably a reason for concern that the various vulnerabilities of
the ODF 1.2 encryption will be too-soon exploitable as a practical matter.
My personal assumption is that no well-informed government body or
commercial entity that is concerned about document confidentiality will
allow use of the ODF 1.x encryption and would require very strong
whole-package encryption techniques, whether defined for ODF documents or
not. In that regard, the ETSI draft that we have been asked to comment on
has moved ahead of us in the level of confidentiality-by-encryption that it
attains for Zip-packaged documents.
- Dennis
Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php