Ask Your Question

I forgot my password to a very important document Please Please help. I'll get fired

asked 2018-02-08 14:03:51 +0100

MamaIreneY gravatar image

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 flag offensive 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!


librebel gravatar imagelibrebel ( 2018-02-10 02:20:33 +0100 )edit

3 Answers

Sort by » oldest newest most voted

answered 2018-02-08 14:25:03 +0100

Lupp gravatar image

updated 2018-02-09 20:01:49 +0100

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)

edit flag offensive delete link 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.

librebel gravatar imagelibrebel ( 2018-02-09 13:48:38 +0100 )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.

Lupp gravatar imageLupp ( 2018-02-09 18:22:09 +0100 )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]

librebel gravatar imagelibrebel ( 2018-02-09 22:30:08 +0100 )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.

librebel gravatar imagelibrebel ( 2018-02-09 22:34:49 +0100 )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.

Lupp gravatar imageLupp ( 2018-02-09 22:51:37 +0100 )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.

ajlittoz gravatar imageajlittoz ( 2018-02-10 08:07:51 +0100 )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 the Save as... dialogue.

Lupp gravatar imageLupp ( 2018-02-10 09:30:47 +0100 )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?

ajlittoz gravatar imageajlittoz ( 2018-02-10 09:45:12 +0100 )edit

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

ajlittoz gravatar imageajlittoz ( 2018-02-10 11:56:44 +0100 )edit

No idea if the information in this article is still accurate, but an interesting read nonetheless :

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

librebel gravatar imagelibrebel ( 2018-02-10 14:06:32 +0100 )edit

answered 2018-02-10 17:17:05 +0100

ajlittoz gravatar image

updated 2018-02-10 20:04:01 +0100

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)

edit flag offensive delete link 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.

Mike Kaganski gravatar imageMike Kaganski ( 2018-02-10 18:46:31 +0100 )edit

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

ajlittoz gravatar imageajlittoz ( 2018-02-10 20:05:40 +0100 )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.

Mike Kaganski gravatar imageMike Kaganski ( 2018-02-10 20:13:09 +0100 )edit

answered 2018-02-12 00:15:50 +0100

librebel gravatar image

updated 2018-02-12 16:53:06 +0100

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.


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.
REM See:

    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 & "Passwords Tried: " & g_CurrentPasswordCount & 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 #################################
Global g_CurrentPasswordTry As String
Global g_CurrentPasswordCount As Long
Global g_MaximumPasswordTries As Long
Global g_AbortTryPasswords As Boolean
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.
    g_CurrentPasswordCount = 0
    g_AbortTryPasswords    = False  
    Dim aProps(0) As New
    aProps(0).Name = "InteractionHandler"
    aProps(0).Value = CreateUnoListener( "my_PasswordInteractionHandler_", "com ...
edit flag offensive delete link more
Login/Signup to Answer

Question Tools



Asked: 2018-02-08 14:03:51 +0100

Seen: 1,482 times

Last updated: Feb 12 '18