I have a writer document for my job. I went to open it and have forgotten the password. I will get fired if I can't open and fix this

edit retag close merge delete

Hello @MamaIreneY,

In the mean time you could try the tips from this wikihow article:

How to Remember a Forgotten Password

Good luck!

lib

( 2018-02-10 02:20:33 +0200 )edit

It's been well over a year now. How did your luck play out?

( 2019-06-01 01:15:12 +0200 )edit

Sort by » oldest newest most voted

I came back to this old thread due to a recent mention of it. A test of the attached helper sheet showed that the behaviour of LibO had changed. There were annoying prompts needing to be cancelled one by one. This to the effect that an unattended run of the automatism for many passwords in one go was no longer possible.
In case somebody wants to run the helper, please use this slightly reworked version of the sheet originally attached more than 2 years ago.
(I added a parameter to the property-array used when trying to open the encoded file.) [/edit]

First of all stay cool and try to remember. If you don't remember every detail, a few things you are sure about can help. If you try anything don't do it with the original file, but with a copy.
Did you save to odt?
'Save with password' will encrypt a file with a rather strong algorithm. In specific if the password is not very long, and you remember something about it, there is a chance to attack the encryption using "brute force" algorithms. Unfortunately I cannot recommend a specific software. Hopefully someone else will come with more specific advice.

Might someone with related experience try to help?
I just know how to test for each one in a collection of probable passwords by user code, and this way pretty much faster than one by one "manually", but I have no evaluated concept of generating the collection from partial knowledge of the PW.

In case somebody wants to ease and to also speed-up a bit his (f/m) search for a forgotten password, he may use this provisional spreadsheet for the purpose. On my system it needs about 350 ms to test for a wrong password, and thus about 1 h for the 10000 it is prepared for. I do not know a faster way. The expense in time is due to the 'loadComponentFromUrl' command from the api. It's not a matter of "poor BASIC". If the correct password is found eventually, the delay can be much longer - but that's pure joy then. Proposals concerning support for systematic guessing by user code would be valuable.

(Using the sheet with AOO is basically possible, but there will be some annoying experiences, and the final MATCH will not work. Tested with AOO V4.1.5)

more

Very interesting @Lupp, I have no experience in this, however i imagine that partial knowledge of the PW could be represented each as a condition like “Starts With <pwfragment1>”, “Contains <pwfragment2>”, Ends With <pwfragment3>”, etc., depending on any fragment that the OQ remembers.

Would be interested in helping out implementing this.

( 2018-02-09 13:48:38 +0200 )edit

Yes, I even considered a kind of form to ask the "forgetter" for remembered elements/properties. To write a generator for all the passwords matching the form should, however, be the real task with this issue.
If you (@librebel ) are interested, or have some experience with existing software addressing the issue, I would like to know. I made a preliminary .ods handling an explicit list of probable PW, and may add a generator for permutations, e.g.

( 2018-02-09 18:22:09 +0200 )edit

Such a form would be priority #1 in my opinion, since any piece of information recollected from the user’s memory, including uncertainties, can drastically decrease the search space. Search time could be decreased by prioritizing search areas based on, for example, a likeliness distribution for password Length specified by the user. Finally, filling in the form itself might already trigger a full recollection of the password from the user’s memory, ... [continued in next comment]

( 2018-02-09 22:30:08 +0200 )edit

[...continued] especially if the questions are phrased in such a way that it forces the user to think back about the times and circumstances in which he thought of that password in the first place.

Thanks for the sheet @Lupp, it will serve as the basis for the provisional “LibreOffice Password Cracker”.

I think a limit of 10000 is not neccessary, the unsuccesful guesses do not have to be stored in the sheet.

( 2018-02-09 22:34:49 +0200 )edit

@librebel: 10000...
I tried to respect the spreadsheet-do. Of course you may use the sheet only to provide the form and as a container for the code doing everything in the background then. My intention was to create a set of PW for testing by whatever means (code again likely) and to visualise it in a range of the sheet.

( 2018-02-09 22:51:37 +0200 )edit

Which cipher algorithm and key length are used? What exactly is encrypted: the .odt file as a whole, subdirectories in the zip? Are there fixed data at the beginning of the encrypted part (for the known-cipher-text method of attack)?

I know that with strong algorithms this is very hard, but it could give a few bits in the key.

( 2018-02-10 08:07:51 +0200 )edit

@ajlittoz: Thats'interesting. Would you, please, explain this to more detail? Assuming that the encryption was done by the algorithm LibO comes with, I don't know any means to control the process beyond enabling the Save with password option.in the Save as... dialogue.

( 2018-02-10 09:30:47 +0200 )edit

@Lupp: well this needs some lengthy explanation not compatible with comment limited space. Do you know a way of exchanging e-mail addresses without exposing them in the open?

( 2018-02-10 09:45:12 +0200 )edit

@Lupp: I delete your comment with your access method to preseve privacy.

( 2018-02-10 11:56:44 +0200 )edit
1

Decrypting Open Document Format (ODF) Files – by K. Udo Schuermann

( 2018-02-10 14:06:32 +0200 )edit

From a quick investigation, enlightened by the note referenced by @librebel, the hope to recover your file with cryptanalysis is next to nothing. @Lupp's idea may be one of the best alternatives.

An .odt file is in fact a zipped directory (change extension odt to zip and you'll be able to decompress it). In this directory, file META-INF/manifest.xml describes all other components in a <manifest:manifest> XML element with nested <manifest:file-entry> elements.

When a file is password protected, the file-entry element contains a <manifest:encryption-data> elements with subelements giving details on how this file was encrypted.

To improve protection against cryptanalysis, the file is zlib-deflated (to reduce entropy) before being encrypted. This means that instead of having fixed prefix of <?xml version="1.0" encoding="UTF-8"?> + Return, we have a much shorter run of bytes (of which the last is not reliable because some bits can be used for what follows) against which to test our guesses.

The password provided is first mangled through a process names key derivation so that the bits are made more random than printable characters and the resulting key is 32 bytes = 256 bits long. Such a length is not in the cracking reach of poor amateurs like ourselves. To complicate matters, the salt, i.e. an initial value for some register, is different for each file, meaning any knowledge we may have gained on a particular file is of no use on the next file.

The <manifest:key-derivation> element tells us that 100000 (yes 100k) iterations are made before obtaining the key; with as many iterations, bits in the key are no longer visually related in any means to the human password.

Once this key is manufactured, it is used in the AES-256 with CBC mode with a random initialisation vector specific to each file. The fact that the initialisation vector is explicitly given in the element does not help much.

Worse, I made a test to see how these data were "permanent": they change every time you save your file. It is likely that both salts and initialisation vectors include some form of save operation time-and-date.

The morale of the story is you can't hope to break the encryption because strong cryptography is used here. Brute force will do nothing: supposing we can make one test every millisecond, compute how long are 2^256 milliseconds (there are 86400 seconds in a day, rounded to 100000=10^5, 2^256 rounded to 10^85; that makes 10^78 seconds and 10^9 seconds is roughly 30 years).

Since password protection offers the possibility to protect a file, yet make it possible to share it with another password, this meant for me that both passwords would hide the real key stored somewhere in the file. You encrypt with only one key, therefore having two access passwords needs an intermediate step to grasp the key, the software then makes a difference in what you are allowed to do ...

more

recently, we worked along with developers from JohnTheRipper, who found a bug in our hashing algorithm. They were implementing an algorithm to break our protection. So you could look at their development version that should have this feature.

( 2018-02-10 18:46:31 +0200 )edit

@Mike Kaganski: this may be good news for OP. His file is surely old enough to be exposed to the bug.

( 2018-02-10 20:05:40 +0200 )edit

The bug doesn't make the security worse; it just made the algorithm not conformant to standard. So no good news in that sense. I only mentioned that because now I know that they have a cracker for ODF files.

( 2018-02-10 20:13:09 +0200 )edit

For the average commuter user, all the information given on retrieving a forgotten password for a crucial libre office document can be summed up as "You're screwed"

( 2019-10-30 22:17:45 +0200 )edit

True. Which is the result of the other side of the same thing: "you can rely on the security the password gives you. It's really strong protection against unauthorised access".

( 2019-10-30 23:09:10 +0200 )edit

Hello Everybody,

The Original Question was already answered in the best possible way by @Lupp and @ajlittoz; All hope for the OQ at this moment is located somewhere in her own memory… You know you can do it!!

Building forth on the “Password Spreadsheet” provided in the answer from @Lupp, i would like to propose in this answer box a faster way to test the Passwords by which to open an encrypted LibreOffice document.

Instead of calling LoadComponentFromURL() for each Password to test, this proposal calls LoadComponentFromURL() only once for the encrypted document to be opened, and then uses a Password InteractionHandler to keep on re-entering new passwords for that Document, until the correct Password was entered, or until the “list of Passwords to try” has been depleted.

The “list of Passwords to try” is yielded by the function YieldNextPassword().

The intention is to make it into a “smart yielder” that generates the most promising passwords, based on a prefilled spreadheet containing any fragmentary bit of information about the real password from the user’s memory.

NB. i tested this method on my old laptop, and found that it is indeed faster ( about 30% faster ) than the method of calling LoadComponentFromURL() each time.

Code:

REM  *****  BASIC  *****
Option Explicit

Sub Main
REM Execute Main() to test the method TryPasswords() for the Document URL specified below:
REM Could take a long time to complete, depending on the value for g_MaximumPasswordTries specified below:
REM To stop the macro prematurely, click on the red Stop button in the Macro Editor window.

Dim strURL As String   : strURL = "/home/user/Desktop/testPW.odt"   REM Set here the encrypted Document to open.

g_MaximumPasswordTries = 100        REM Set here the maximum number of tries after which the process will be aborted.

Dim lStartTime As Long : lStartTime = Timer             REM Record Runtime Duration.
Dim oDoc as Object     : oDoc = TryPasswords( strURL )  REM Runtime1 = Try Passwords with interaction handler.
'   Dim oDoc as Object     : oDoc = TryPasswords2( strURL ) REM Runtime2 = Try Passwords with repeated calls to LoadComponentFromURL()'
Dim lEndTime As Long   : lEndTime = Timer
Dim lTotalSecs As Long : lTotalSecs = lEndTime - lStartTime

Dim strMsg As String   : strMsg = "Document : '" & strURL & "'." & chr(13)
strMsg = strMsg & "Password Found : " & g_CurrentPasswordTry & chr(13)
strMsg = strMsg & "Total Seconds  : " & lTotalSecs & chr(13)
If Not IsNull( oDoc ) Then msgbox( strMsg, 64, "TryPasswords - SUCCESS!" ) Else msgbox( strMsg, 16, "TryPasswords - FAILED!" )
End Sub

REM #################################
REM #################################

Function TryPasswords( sURL As String )
REM Tries to open an encrypted LibreOffice Document by entering passwords from a given set.
REM Faster Method : by interaction handler.
REM <sURL>  : The File Path or URL to the encrypted Document that we are trying to open.
Dim aProps(0) As New com.sun.star.beans.PropertyValue
aProps(0).Name = "InteractionHandler"
aProps(0).Value = CreateUnoListener( "my_PasswordInteractionHandler_", "com ...
more

Never password protect a document in Libre office

more

1

Of course you are right! Because it's something that would make impossible for anyone without the password to open the document - including yourself in case you forgot it; and naturally you are password-protecting your important data just to allow everyone to have some workaround to open the data without the password! Who could even imagine that you need the password to open the password-protected document?!

( 2019-10-31 03:28:59 +0200 )edit