[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] The problem of visible hashes for protection keys
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]