Security and password protection

This chapter is centered around information on privacy, security, and user rights involving ODF documents and supporting implementations.

ODF provides document encryption as a means to restrict access to content of a document (document security), passwords to restrict certain activities (protection locks) and digital signatures. Digital signatures are about user (signer) authentication and verification of content integrity.

It makes sense make a distinction between document level security and user security. Document level security revolves around retaining the confidentiality and/or integrity of content. The key issue surrounding user security concerns malicious embedded macros that can be used by an attacker to take over a user’s computer system. There is a separate chapter on how to migrate away from using macros in documents.

Except for digital signatures, all privacy and security provisions in ODF documents are password based. This means that users will be able to exert typical behaviour (e.g. use of weak passwords and reuse of memorable passwords) which makes them subject to exploits. Passwords used with documents are particularly vulnerable because they are subject to off-line attack and the documents may contain information that might assists password discovery.

Document Security: Encryption

Document encryption completely locks the document from probing eyes. When an ODF document is password protected the file structure of the bundle remains the same, but contents (of XML files in package) are encrypted using following algorithm:

1. A digest of the user entered password is created and passed to the package component (hash).
2. The random number generator (current time is used as seed) is used to generate a random 8-byte initialization vector and 16-byte salt for each file. The initialization vector and the salt are stored in manifest file
3. Salt is used together with the hashed password to derive a unique key for each file..
4. The derived key is used together with the initialization vector to encrypt the file in cipher-feedback (CFB) mode.

Prior to ODF 1.2 the key was SHA1 and the encryption was Blowfish. Since standard use of SHA1/Blowflish as encryption does not meet FIPS-140 and a number of other government standards, ODF 1.2 added the possibility to use other algorithms. Apache Open Office (as of version 3.4) and LibreOffice (as of version 3.5) added SHA256/AES to their encryption repertoire.

As of 2023 SHA256/AES is still considered reasonably secure. This means that without the password, the document cannot be loaded without significant effort. If you lose or misplace the password it is extremely difficult, if at all possible, to recover its contents.

Protection Locks

ODF provides a mechanism to lock specific parts of text to certain activities. It too uses a password but it’s not for encryption but to set user rights. Once you put a password, for example, on a section, you will be prompted for that password before receiving any dialog that might have a chance to access that section of text. The password is the key to the right.

Protection locks are best viewed as simple safeguards against accidental alterations. They provide little security as they are easy to over-ride by editing the XML files. Do not assume that protected fields or pages cannot be and have not been altered. No great skill is required to subvert the protection and there are a number of software programs that provide this “service” (useful, for example, when you misplace a password).

Do not use a memorable password that is used for anything else when setting protection locks as they are not well protected. The password can be trivial or, better yet, random and not remembered (but retain a copy of the unprotected document).

General remarks on the safety of using passwords

Passwords used for protection features are inherently insecure. A password used to set protection on a document that is shared with others must be considered to be compromised.

Selecting a good encryption password is non-trivial. On the one hand, it should be complex and non-obvious enough for others not to easily guess it but also be sufficiently simple to remember.

Don't use words from any language. Words in a dictionary are highly susceptible to what is called a dictionary attack. Sprinkle numbers, punctuation and other symbols into your password to enhance its security. When you use letters, numbers and symbols, it makes your password more difficult to guess. Increasing its length also increases its complexity and makes brute force attacks more costly.

Safety of working in the cloud

If you have important documents that require confidentiality, for instance because they contain identifiable information on citizens or content that is strategic to your organisation, working in the public cloud is probably normally not an option. If the document resides on the server unencrypted or (as is the case with solutions like Google Docs) if your key strokes leave your browser, the entire contents of your document should be considered at risk.

One notable exception is if you are able to control where the content is stored and encrypt everything *before* it leaves the browser. The RemoteStorage protocol is focused on enabling separation of concerns between the application creator and where you want to store your documents, but separate applications need to be developed.

Save with password

The "Save with Password" feature uses digital encryption defined in the ODF specification. Where implemented by ODF-supporting software, "Save with Password" is useful for preventing accidental disclosure of private records created by individuals and not intended for sharing with others.

The document is encrypted using techniques that required the password to be known. If the password is lost, or no longer works when software is changed or replaced, there is no means for recovering the password or the document available to ordinary users.

For this kind of personal, individual use, techniques for encryption of hard drives may be preferable. That ensures that working documents, auto-save files, and original materials used before (or instead of) "Save with Password" are also protected against scrutiny. Local administrative policies governing disk encryption and registering of passwords must be considered.

For sharing of documents in encrypted form, the password must also be shared using some private means. Generally, the password is the weakest link, although disclosure of the password or the document's plaintext by recipients, even inadvertently, is additional risk.

Passwords used for encryption of interchanged documents should not be reused for any other purpose and, ideally, should not be reused for encryption of other documents. The passwords need to be strong. Use of password-generation utilities is recommended.

The means of encryption for ODF documents is not highly secure despite the use of recognized encryption techniques. The encrypted document reveals information about the unencrypted form that can aid discovery of the encryption key (different than but derived from the password) as an avenue to decryption of the document by a determined party who obtains possession of the encrypted version.

Weak encryption passwords can be discovered by widely-available attacks. If the encryption key is discovered instead, that also becomes an avenue for discovery of the password itself and making use of it as a trial password for attacking other password uses.

Because of these limitations of ODF encryption, guidelines even for OFFICIAL use may recommend against its employment on document files that are interchanged or otherwise discoverable by third parties. There may be limitations among implementations that confine successful interchange to users of the same software versions as well. Not all ODF-supporting software supports ODF encryption. Also, format conversion is possible only after decryption.

Digital signatures

The digital signature provisions for ODF documents avoid interchange of private passwords by relying on public-key technology.

The commonly-implemented basic digital signing is generally workable, with greatest success at verification using the same software product used for signing. Straightforward use is also generally successful between products that support digital signatures. Digital signatures in the ODF 1.3 specification are different than the non-standard signatures introduced as extensions by implementations of earlier ODF specifications.

Signing by ODF implementations is performed on the saved document. Any number of signatures can be affixed, by different parties at different times, providing a form of counter-signing.

The common implementation does not carry any assertions with regard to what the signing attests to. The signature applies to the document files and everything in it, whether known to or presented to the signer in a perceived document.

XAdES extensions used in ODF digital signatures carry further information about the role of the signer and the purpose of the signature. While few implementations support specification and presentation of the XAdES data, such signatures remain verifiable and XAdES should be used wherever support is available.

Again, guidelines and policies for OFFICIAL documents should be consulted for the use of public-key certificates, required signing techniques (such as use of time-stamp systems) and the treatment of digitally-signed materials.