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

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@lists.freedesktop.org 
[mailto:libreoffice-bounces+dennis.hamilton=acm.org@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