[Libreoffice] [REVIEW] patch for fdo#38561: can't save pw protected file without pw

[Dennis E. Hamilton]

The "Change Password" feature is not present in LibreOffice 3.3.2.  It does appear in some sort of partially-implemented form in LibreOffice 3.4.

I suspect that there may be interference of that feature with encryption-password handling.

 - Dennis

ESSAY ON ENCRYPTION VERSUS LOCKING AND HOW DIFFERENT THEIR PASSWORDS ARE

We need to remember that password use for encryption (i.e., Save As ... dialog Save with password check box) is very different from a password used for locking things in the document.  

Lock passwords are inherently insecure, since the hash is recorded in the document.  So it is really not doing much harm to cache them, although they are a potential security exposure too.  (I can understand why one might create and hold onto multiple hashes for a lock when it is not known which hash will be required by a format the document might be saved in and also while the user may still be fiddling with lock settings.)

ENCRYPTION PASSWORDS DO NOT NEED A CACHE

Encryption passwords should not be retained very long, and there is only one hash needed for an encryption password.  Since it is known at the time the Save As ... is being done which initial-password hash algorithm will be used, this is when the password should be requested.  As soon as all the key generations have been done and the file saved in encrypted form, that hash should disappear.  There is no meaningful further use for it and it is a critical secret.  Knowledge of that hash is enough for an attacker to be able to decrypt the document.  Any memory residue of the original password and the hash used for encryption key generation must be obliterated as soon as possible for each of them.

Even if there is a future provision for ODF 1.x encryption following signing (i.e., on an already-saved document), the password should not be requested until the encryption process is prepared to commence.  So again, there is need to produce only the one initial password hash, depending on what the implementation of password-based key derivation requires, and that hash should disappear from memory (ideally, the stack or a randomized local heap allocation) as soon as the encryption completes.

For decryption, the need for a password or its hash is likewise of short duration.  Fitting the decryption password-hash into some common hash cache is not only unnecessary, it risks disclosure.  Furthermore, on the off chance that a user uses the same password for encryption and for locking, there is an exposure to having a lingering cache even for locking, though if a machine is compromised the cache is the least of our worries.  

(Lock hashes are inaccessible in an encrypted document, but unencrypted documents from the same party definitely provide a source of hashes that one would try first in an attack on an encrypted document.)

THIS MAY BE AN INTERFERENCE WITH CHANGES FOR LOCKING

The partially implemented "change password" button on the LibreOffice 3.4 Document Properties | General tab, if related to encryption, doesn't make any sense to me.  If it is related to document protection (not encryption) it is in the wrong place.

CALLING THE WRONG THINGS "SECURITY" IS NOTHING BUT TROUBLE  

Calling protection a security feature is also problematic since locking a document against writing or making untracked changes is not a security feature.  Protection (not encryption) in all forms is trivially subverted unless the document is signed, and that's an authenticity feature, not a security feature.

If we are so confused about what is security and what is not, how are we helping users adopt safe practices and to, possibly, comprehend what is unsafe about actions they find convenient.  I am thinking about the tendency to use the same memorable password for something as trivial as a lock and as important as an encryption password or for something even more valuable.

I have a utility on my computer that will crack SHA1 hashes of not too long, memorable passwords in mere seconds using a well-crafted brute-force attack and the high-end GPU of my video card.  Putting password hashes where they can be retrieved and attacked is an arms race we cannot win by simply choosing more complex hash algorithms and allowing users to believe their lives have been made more secure.

 - Dennis

-----Original Message-----
From: libreoffice-bounces+dennis.hamilton=acm.org at lists.freedesktop.org [mailto:libreoffice-bounces+dennis.hamilton=acm.org at lists.freedesktop.org] On Behalf Of Markus Mohrhard
Sent: Monday, June 27, 2011 01:40
To: Andras Timar
Cc: libreoffice-dev
Subject: Re: [Libreoffice] [REVIEW] patch for fdo#38561: can't save pw protected file without pw

Hello Andras,




	It's not clear to me why the functionality works in 3.3. Encryption
	data is not cleared there, too.
	
	


I only had a closer look at the xls export and we didn't use the EncryptionData in the export there, at least not to detect if the file is pw protected. There we used the SID_PASSWORD entry witch was cleared in both cases. I think it was the first step to some changes that we have in master where the pw code was changed in several places.

Regards,
Markus