Apache OpenOffice (AOO) Bugzilla – Issue 126499
Cache Default Password for use with Password-Protected Files
Last modified: 2017-05-20 10:45:07 UTC
It would be really useful if there were some mechanism for entering a default password into AOO, which the application would then cache and use as the default password when opening password-protected files. If you use the same password for all password-protected files - just as a rudimentary security measure, like I do and I'm sure a lot of users do who use password-protection - then such a feature would avoid the need to enter the SAME password EVERY time you open a password-protected file. There are several possible ways of implementing this, such as: (1) When you open a password-protected file, there could be a tick-box on the Password dialogue box that says "Remember Password", and this password would then get cached by the application; opening subsequent password-protected files, the password could then already be completed in the dialogue box. (2) Have an Options... setting (in the Security section) where you can specify "Enter default protection password at application start-up", so that when you start AOO (eg. Quick Starter runs) you are asked for the default password to use (a bit like "logging on" to the application) which would then be used when opening a password-protected file (possibly silently, ie without the Password dialogue box appearing). (3) On one of the menus, have an "Enter default password" menu item where you can enter the password to be used by default when opening password-protected files. Obviously, the password would only be cached in memory while the application was running. Also, if a default password has been entered, then the "Save with password" option should be selected by default on the "Save As" dialogue box, with the passwords automatically being completed on the subsequent "Set Password" dialogue. My personal preference for implementation would be (2) followed by (1), the reason being that it would make it trivial for users to password-protect ALL of their AOO files (and do so transparently, in the case of (2)), thereby adding a layer of security to some of their documents without adding any inconvenience.
I disagree with your suggestion. If you won't be able to remember a password, don't use it. For me, security is the responsibility of the operating system, and not software.
You miss the point. It is not a question of the user not REMEMBERING the password, it's a question of REPETITION (having to enter the SAME password EVERY TIME you open a file). In other words, you should only have to enter the password ONCE in AOO. (As an analogy, you don't have to enter your password EVERY time you open an email, do you?) And it's all very well saying that security is the responsibility of the operating system, but the user doesn't always have control of the OS's security, eg when storing files in the cloud. Furthermore, if the OS security were sufficient, AOO wouldn't provide the facility to password-protect files in the first place...
If you have several files to protect, the best way is to attribute folder restrictions. For me, this kind of mechanism is a security hole for AOO.
One thing that is not being addressed directly here is the threat model. Security considerations are non-trivial. What is the threat model of AOO remembering passwords used in the encryption of ODF documents, assuming there is a way to know which documents have what passwords? Is there an increase in what is termed the threat surface, and is it tolerable? If it is a default password case, maybe elicited on startup of OpenOffice, it means that the cached password is held even if it might not be used. What is the threat model of that being retained in the program somewhere for an indefinite time? If the default password is to be retained across sessions, that means whatever is retained is made persistent somewhere. Is the resulting threat model tolerable? There is also the problem of what happens when the cached password doesn't work on a particular document. That will be detected as a decryption failure by a technique that is part of the decryption procedure. That could well be because an unprotected document has been created for the purpose of eliciting the user's re-entry of their memorable, reused password. The current model has a security barrier at a particular simple place. When OpenOffice is being used to open a document, whoever is at the user's desktop computer at the time must offer the correct password at that time. It (actually, a derived hash of it) needs to be retained only long enough to decrypt the document as needed and then all evidence of it can be erased. (There remain threat model issues on where the decrypted bits of the document file are placed and whether or not they can be retrieved by others then or later.) If one is not terribly concerned about protection of documents except for their personal use, this potential weakening of security for all users is perhaps not the direction to take. The threat to one user may be an uninteresting use case for some, but not for others. I am only saying that one must look both deeper and wider in looking at this request. I have also changed this issue from DEFECT to ENHANCEMENT.
I appreciate that this may have ramifications for the threat model, but this feature is intended to be used by those users that employ password-protection of AOO documents simply as a rudimentary protection mechanism, not for those users wanting to protect highly classified/confidential information: such users shouldn't dream of using something like password cacheing! For example, I might need to put a copy of a document on a USB stick to transfer it to another device. If, on the off-chance, I happen to lose that USB stick, I don't want the person who finds it to have the ability to just open the document and read it (and no, I don't want to encrypt the USB stick because the other device might not be able to handle encryption). The password-protection on the document is sufficient security for my peace of mind. However, I also want the convenience of being able to open all of my password-protected documents on my home PC by entering the password into AOO only once (per execution of AOO). Remember that this feature will be optional: users won't have to use it, but it should be there if they want to. Please can oooforum be removed from this issue as they are not contributing anything useful or relevant. Thank you for changing the issue type to ENHANCEMENT - I didn't realise I could do that.
(In reply to apache.org from comment #5) > I appreciate that this may have ramifications for the threat model, but this > feature is intended to be used by those users that employ > password-protection of AOO documents simply as a rudimentary protection > mechanism, not for those users wanting to protect highly > classified/confidential information: such users shouldn't dream of using > something like password cacheing! [ ... ] Thanks, I think your use case is very important for thousands of users. I suspect you understand what I am sketching below, but this may be valuable to others. You covered the USB stick (or even email) transfer issue, especially when email encryption os too complicated or not necessarily understood by a recipient (though there becomes a key management issue and we don't have to address that here). I think the use of security barriers by the knowledgable user in this case can be handled in this manner. 1. If the user has exclusive access to the device being used, boot security should be employed. That is, BIOS settings or other provisions should introduce a password requirement for startup. 2. The hard drives on such a system should be encrypted. (Notice that Bootlocker accomplishes both of these, and it allows a USB drive to be used to provide the key on hardware that recognizes USB drives at startup. Other platforms may have comparable provisions. Note that (1-2) are valuable if there is theft of the device or an attempt to use it when the exclusive user is away from the shut-down machine. 3. If the computer is shared, (1-2) can still be desirable, but it now involves a shared secret. 4. If the computer can have multiple accounts, be sure to create an individual account that requires password login. 5. For documents worked on in that account, ensure that the account-specific folders used to work on private documents are encrypted (especially if 1-2 are not employed). Note that this is folder encryption and, while access from a non-administrator/root account should already be implemented, it also deals with loss of the computer and hard drive. 6. For the screen saver, use one that requires a re-login to unlock and access the currently-active account. Set parameters for automatic initiation of the screen saver that fit your work habits. 7. When leaving the computer unattended for any short time, activate the screen saver immediately by whatever provision there is, especially if there are others in the area and you do not wish your work observed or your account used in your absence. These are all steps that are valuable regardless of the productivity software being used, if the computer and operating system support them. Running an application is not a very good security boundary, especially in the absence of these access precautions. The next available security boundary is the password protection on the files themselves. Are the steps described above also effective with regard to private use document protection and also deal with the desktop access and physical control boundaries (especially theft or hard-drive access) as well as can be expected?
Yes, what you describe is a very comprehensive security protocol for protecting (all of the) data at a device-level (ie you are securing the entire device and its contents); using AOO's password-protection feature provides protection at the file level (ie you are securing the actual data itself). The difference is like having an unencoded (physical) written message stored in a safe or the same message written in a secret code - both are secure but at different levels. The former is secure while in the safe, the latter is always secure - whether in a safe or not.
We could passwords easier by doing what eg. Firefox does when remembering passwords for websites: have a single master password which is used to encrypt all cached per-document passwords, and require the user to enter the master password to retrieve and decrypt the password (if present) for a document when opening it. That way, security isn't decreased while the benefits would be similar: whatever password you use for documents, you only enter it once and it would be remembered by OpenOffice after that, you only have to remember the master password.
(In reply to damjan from comment #8) > We could passwords easier by doing what eg. Firefox does when remembering > passwords for websites: have a single master password which is used to > encrypt all cached per-document passwords, and require the user to enter the > master password to retrieve and decrypt the password (if present) for a > document when opening it. > > That way, security isn't decreased while the benefits would be similar: > whatever password you use for documents, you only enter it once and it would > be remembered by OpenOffice after that, you only have to remember the master > password. This is an interesting prospect. I wonder how well it addresses the use-case at hand and how many would (learn what it takes to) use it. It seems to me that security isn't decreased only if the persistent password cache is in secure storage and the access to the cache is via a platform-enforced security boundary. Otherwise, the master password and the cache are subject to attack. Do we know how that is done with Firefox on different platforms? Internet Explorer clearly has a way of doing it also. I assume Chrome does as well. Are the threat models different? When encrypted documents are obtained by some means, they are subject to off-line attacks. Securely-delivered passwords to web sites are in a different situation unless the web-site password data is obtained by hackers and also attacked off-line, as does happen.
(In reply to damjan from comment #8) > We could passwords easier by doing what eg. Firefox does when remembering > passwords for websites: have a single master password which is used to > encrypt all cached per-document passwords, and require the user to enter the > master password to retrieve and decrypt the password (if present) for a > document when opening it. This is an interesting alternative, but not exactly the functionality I was requesting - I am just after a single password being cached in memory while the application is running. I believe VeraCrypt (the successor to TrueCrypt) offers such functionality (cacheing up to 4 passwords?). > That way, security isn't decreased while the benefits would be similar: > whatever password you use for documents, you only enter it once and it would > be remembered by OpenOffice after that, you only have to remember the master > password. If passwords are stored somewhere that does then create a vulnerability. It's like storing all of your keys in one safe: they are only as secure as the safe itself...
Reset the assignee to the default "issues@openoffice.apache.org".