I posted on this issue at this website, here: https://ask.libreoffice.org/en/question/307810/how-do-you-fix-password-protection-not-working-in-writer/ Basically the issue is that since updating Libre Office to version 7.0.5.2 (x64), the password protection on it seems to be malfunctioning. I have an .odt document which I save to two USBs. Opening them seems to work alright, as in it requires a password to open it. However, if I edit the document, I no longer get the password protection dialogue box when I try to save it. If the assumption in the update is that if someone opens a document with a password, then, no matter how much later that document is altered, they can be assumed to be the same person, so no password is require, then that is an unsafe assumption. If that is not the case, me ticking to password protect the document when I save the document does not work, as I can keep altereing and saving these documents without entering passwords. I'm new here so I'm not sure how this bug reporting procedure works.
I'm new here. Am I reporting this in the right way? I haven't had any feedback on it. One additional problem that I've had since updating Libre is that on some occasions I've been able to open my password protected document without needing to enter a password. It seems that password protection is broken. Before the update it would always: 1) Require a password to open the document 2) Require a double entry of the password to save the document Since the update that is not always the case.
Thank you for reporting the problem. I can't confir it. Steps: 1. Open a new document 2. Save as => Set password => save and close 3. Open document => LO asks for a password => O. K. 4. Edit the document 5. Save document, close and reopen => still password protected => O. K. 6. Edit the document 7. Save as => "Save with password" is deselected by default (expected). So if you just override the document, it isn't password selected. Tested with Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 4a9eef7849a75ba91806886ea9c96d114c8d56f9 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL So please could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? If the problem ist still there, you can also try it in SafeMode (Help => Restart in SafeMode). I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version and in SafeMode. Change to RESOLVED WORKSFORME, if the problem went away.
Dieter, I am using the 7.0.5.2 (x64) version of Libre Office. I'm not a power user or a computer nerd so I don't want to be downloading alpha versions of the software or whatever and playing in safe mode. The thing that stood out in your reply to me is your step 7. This seems to be the issue as this procedure is new and was not the case with my previous version of Libre Office. Think about the implications of this default: Someone creates a password protected file. They leave the document unattended and a stranger comes by and alters or deletes the document without the owners knowledge because no password as is required to do that, as used to be case. What is the logic of the change? Is it an improvement on the system which existed before, where any changes to the document required a password to carry them out? In any case, I created a new document on my current build of Writer and used the Save As function to backup the document and I had the box ticked for creating a password. I accidentally saved it to my PC, instead of my USB, as I had intended to. When I made changes to the document and clicked to Save As, no password was required. A password was not required when opening the document after I had closed it after the first time that I had saved changes. It looks like the box for password protection was not ticked. My previous version of Libre Office must have had the box for password protection ticked by default when it came to that document in particular. That is the sensible default behaviour for the software. The change in software behaviour is bad on many levels, mainly for security and privacy reasons.
(In reply to StromenNorman from comment #3) > The thing that stood out in your reply to me is your step 7. This seems to > be the issue as this procedure is new and was not the case with my previous > version of Libre Office. This might be a consequence of bug 133771. Xisco, Vasiliy, you've worked on bug 133771. What do you think? cc: Xisco Fauli cc: Vasiliy Melenchuk
Hi reporter. Bug reporting is per https://wiki.documentfoundation.org/QA/BugReport, needs to be objective, with Experienced and Expected steps and use case, as here. Any further talk obscures the issue. I glanced and didn't see a problem. So please write steps. "Stranger" is not acceptable use case. Until clarified, no need to have dev here, removing Vasiliy.
(In reply to Timur from comment #5) > Hi reporter. Bug reporting is per > https://wiki.documentfoundation.org/QA/BugReport, needs to be objective, > with Experienced and Expected steps and use case, as here. > Any further talk obscures the issue. I glanced and didn't see a problem. So > please write steps. "Stranger" is not acceptable use case. > Until clarified, no need to have dev here, removing Vasiliy. Timur, steps are provided in comment 2. So question is, if behaviour is expected (I think yes) or not (bug reporter). Is it the intended behaviour after fixing bug 133771 or a negative side-effect. I can't assess, but perhaps you can?
I see. That's why I asked reporter to confirm. Doesn't look like a bug to me.
I can confirm I have the same problem - the password has been removed on a text document that was previously password protected without requiring the password. I first noticed it in the 'recent documents' view in Calc it shows the first page of the document rather than the blank page one normally gets in that view. The calc password protection still seems to be working. The change password function is greyed out and even if I change the security settings it will not allow a new password to be set. I have also tried resaving the protected document under a new name and still the same problem - the password protection no longer exists and it is not possible to set a new password To me this is a large security hole as it allows access to any password protected ODT documents. It also demonstrates that however strong the password encryption is it can easily be bypassed.
Stromen and John, what you reported is user story and personal experience. What bug report needs are steps and Experienced and Expected results (and use case).
Dieter, I have pretty much given up on this getting fixed. It is a new issue. Writer is doing something which it wasn't doing prior to me lodging this bug. I'm not schooled in the ways of bug reporting and, as you can tell, I'm not making a point of following this bug up. All I can say is that this bug comes into play once you have edited a saved document. Once you have edited the save document, the box for password protection is no longer ticked, I think. It's been not too many weeks since I last had this problem, so the details aren't fresh in my memory. I.e. I'm not sure how the Writer programme behaved if you made a point of having the Save With Password option ticked. Since I'm not chasing this massive security hole problem here, I'll just say: 1) Why does the Writer programme (7.0.6.2 x64) no longer DEMAND that you type in your password IF you edit the document? That is a MASSIVE security flaw. Why give anybody the ability to edit YOUR document? 2) What does the Writer programme now no longer have the box for Save With Password ticked on a document which is ALREADY password protected? I'm only replying to this thread because I got a notification that somebody else had reported the same problem here. I've done my part as far as I'm concerned. If anyone else notices this massive security hole they can do all those geeky things that you require to fix this issue.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to StromenNorman from comment #10) > 1) Why does the Writer programme (7.0.6.2 x64) no longer DEMAND that you > type in your password IF you edit the document? That is a MASSIVE security > flaw. Why give anybody the ability to edit YOUR document? This part has not been discussed yet. Leaving it to QA to test whether opening and editing had separate PW checks in the past. Or if this has changed; the PW options include an extra PW to allow editing. > 2) What does the Writer programme now no longer have the box for Save With > Password ticked on a document which is ALREADY password protected? The point of SaveAs is to create a new document. And by default documents are not protected. So we have a good argument for the current state. It would be helpful to describe a use case. For example, "I use a protected template and expect the documents created based on it to be protected as well.". Sounds reasonable to me and easy to resolve. (In reply to Dieter from comment #4) > Xisco, Vasiliy, you've worked on bug 133771. What do you think? Waiting for this input.
(In reply to Heiko Tietze from comment #12) > The point of SaveAs is to create a new document. And by default documents > are not protected. So we have a good argument for the current state. It > would be helpful to describe a use case. For example, "I use a protected > template and expect the documents created based on it to be protected as > well.". Sounds reasonable to me and easy to resolve. Well, the use cases with "Save As" aren't simple at all. We have to take into account that with "Save As" you can select a format that doesn't support password protection at all, or does support password protection, but is incompatible with the current document password protection (ODT save as DOCX for example). So in general you have 3 possibilities if the document is password protected: - target document format doesn't support password protection -> need to inform the user this is the case - target document format is different than source -> need to inform the user and he needs to retype the password again - target document format is the same as source -> no action needed - just use the same password But yeah - there is also password protected templates as you say. Do we want to save the documents with the same password as the template. That's quite tricky...
(In reply to Heiko Tietze from comment #12) > (In reply to StromenNorman from comment #10) > > 1) Why does the Writer programme (7.0.6.2 x64) no longer DEMAND that you > > type in your password IF you edit the document? That is a MASSIVE security > > flaw. Why give anybody the ability to edit YOUR document? > This part has not been discussed yet. Leaving it to QA to test whether > opening and editing had separate PW checks in the past. Or if this has > changed; the PW options include an extra PW to allow editing. > > > 2) What does the Writer programme now no longer have the box for Save With > > Password ticked on a document which is ALREADY password protected? > The point of SaveAs is to create a new document. And by default documents > are not protected. So we have a good argument for the current state. It > would be helpful to describe a use case. For example, "I use a protected > template and expect the documents created based on it to be protected as > well.". Sounds reasonable to me and easy to resolve. > > (In reply to Dieter from comment #4) > > Xisco, Vasiliy, you've worked on bug 133771. What do you think? > Waiting for this input. 1) The programme behaviour that I'm complaining about is new. I.e. in the past, prior to recent updates of the programme, if I edited the password protected document and hit Save As, which is my default choice of how to save a document, the programme demanded that I input the password, twice. That is no longer the case. 2) Why should how I choose to save a document (Save versus Save As) be an excuse for the programme no longer demanding that I input my password, twice? 3) The security implications are blindingly obvious: If my password protected document is open when I'm not around, anybody with access to my PC can alter or delete the contents of that document without needing to provide a password that they are the rightful owner of that document. Well, since I've never tried deleting my password protected document, from memory, I would certainly hope that if I tried deleting an open or an unopened password protected document that the password dialogue box would activate in that case. Tomaz Vajngerl, re your comment that: "Do we want to save the documents with the same password as the template. That's quite tricky...". Maybe you're getting too technical for me. My scenario is of a person using a password protected document and wanting to make sure that it can't be altered by anybody else. You would think that any version of that same password protected document should maintain password protection. The devs shouldn't judge people on how they save documents, limiting what privileges it gives them. If I want to Save As, let me at it.
(In reply to StromenNorman from comment #14) > getting too technical for me. My scenario is of a person using a password > protected document and wanting to make sure that it can't be altered by > anybody else. #1: Create a document and save with password #2: In the "Set Password" dialog, don't encrypt but [x] Open file read-only with a password #3: Open this protected file and SaveAs => must not create an editable version Valid issue and the proper solution would be to not block Save (it's disabled) but ask for the password first. So Save, Save As, Save a copy etc. first show a PW dialog. And once write permission is granted, I don't see a need to keep the PW option checked for SaveAs.
Please clarify what exactly this bug was confirmed for and update the title. I don't see reason for High, if Save as that is a minor issue.
(In reply to Timur from comment #16) > Please clarify what exactly this bug was confirmed for and update the title. > I don't see reason for High, if Save as that is a minor issue. What's missing from my comment 15?
(In reply to Heiko Tietze from comment #15) > (In reply to StromenNorman from comment #14) > > getting too technical for me. My scenario is of a person using a password > > protected document and wanting to make sure that it can't be altered by > > anybody else. > > #1: Create a document and save with password > #2: In the "Set Password" dialog, don't encrypt but [x] Open file read-only > with a password > #3: Open this protected file and SaveAs => must not create an editable > version > > Valid issue and the proper solution would be to not block Save (it's > disabled) but ask for the password first. So Save, Save As, Save a copy etc. > first show a PW dialog. > > And once write permission is granted, I don't see a need to keep the PW > option checked for SaveAs. 2) I cannot see an option to "Open file read-only with a password". Using Save option when I create this document does require a password when reopening the document after you've closed it. Using the Save option when I add text to the document doesn't require a password but you do need a password to reopen the document after you have closed it. Using the Save As option, the box for the password is not ticked, so it's easy to forget that you need to do this in order to MAINTAIN password protection. The previous system was more secure. It just seems common sense that a password protected document should remain password protected however you save it. I also noticed that I could delete this password protected document without having to input a password. I'm not sure what I have to say to demonstrate that this is just really bad security. The old system was better. It made your documents secure. The new system is a giant leap backwards for users.
We discussed the topic in the design meeting. + purpose of readonly is not to block saving but to keep the original document (Maria) + ctrl+a/c allows to copy/paste all (Sascha) + protection prevents changes but does not ensure its readonly via copy/paste or access to the document structure (Sascha) + storing the pw inside a non-encrypted file is an issue too Possible solutions: + show the "readonly" infobar and edit/save after prompting for pw (Heiko) + auto tick the "Save with password" checkbox and let the user insert a pw (or not) in the next dialog (Maria) + use File > Properties: Security > Open file read-only for this kind of protection and remove the option from the save dialog (Sascha) Best seems to reconsider the complete workflow. Leaving it open for Xisco, Vasiliy.
(In reply to Heiko Tietze from comment #19) > We discussed the topic in the design meeting. > Possible solutions: > > + show the "readonly" infobar and edit/save after prompting > for pw (Heiko) > + auto tick the "Save with password" checkbox and let the > user insert a pw (or not) in the next dialog (Maria) > + use File > Properties: Security > Open file read-only for this > kind of protection and remove the option from the > save dialog (Sascha) > > Best seems to reconsider the complete workflow. Leaving it open for Xisco, > Vasiliy. I'm not sure which, if any, of the possible solutions maps onto what the situation was before it was changed for the worst in a later update. At times I have found myself opening documents and wondering why on Earth why they were Read Only. I can't remember if this was on password protected documents or not, but I did find it annoying that such a version of my document was opened without any choice in this matter by me.
(In reply to StromenNorman from comment #3) > The thing that stood out in your reply to me is your step 7. This seems to > be the issue as this procedure is new and was not the case with my previous > version of Libre Office. Used bibisect-linux-64-7.0 to identify that "Save with password" stopped defaulting to true in this situation due to commit e0cced9d4c94324e834e46d807469a0cd6c1f738 Author: Vasily Melenchuk on Mon Oct 14 00:01:52 2019 +0300 do not clean up EncryptionData during SaveAs As the SID_ENCRYPTIONDATA and SID_PASSWORD are used for setting password together, EncryptionData should be removed only when Password was set (reset of Password protection for the document). Elsewhere EncryptionData should remain as is, while it could contain encryption data used for opened document. Reviewed-on: https://gerrit.libreoffice.org/82616
*** Bug 147491 has been marked as a duplicate of this bug. ***
Since I reported the duplicate Bug 147491 I want to drop a line here two: I discovered this when I saved an Excel file from work (that was encrypted with a password) in the .ods format. I just saved it and didn't really look at the options. After I reopened the file, I noticed that the encryption was not kept. After I wondered why for a short moment, I saw that I could have clicked the 'Save with password' box. I was a sloppy mistake of mine that has no consequence at all. However, files are usually not encrypted for fun, but for a purpose. So if an encrypted file is saved with 'save as', the option to save the file with a password should be ticked automatically. If the box is unchecked it should tell you that you are going to save an encrypted file as clear file and everyone will be able to read it. You should have a 'never ask again' option for people who deal with encrypted files a lot. For companies it would may be an interesting setting if you could prohibit a user from saving an encrypted file as unencrypted one.
*** Bug 148060 has been marked as a duplicate of this bug. ***
*** Bug 148215 has been marked as a duplicate of this bug. ***
*** Bug 148416 has been marked as a duplicate of this bug. ***
(In reply to Tomaz Vajngerl from comment #13) > Well, the use cases with "Save As" aren't simple at all. > So in general you have 3 possibilities if the document is password protected: > - target document format doesn't support password protection That is easy. The UI already disables password protection in this case. > - target document format is different than source That is easy. The UI already asks for a password. > - target document format is the same as source -> no action needed - just > use the same password Or ask for a new password anyway. The UI already asks for a new password. I think that makes sense anyway. No need to save with the same password in a different file. > But yeah - there is also password protected templates as you say. Do we want > to save the documents with the same password as the template. Definitely do not save the document with the template password. Thus ask the user for a new password - same as case 3. People are running on two different tracks in this bug report. The off-track people are talking about bug 148416 - an open-as-read-only document that requires a password to get into edit mode. This bug report is talking about a file that needs a password in order to open. For instance, attachment 178351 [details] from bug 147491. So the simple fix seems to be to just revert one line back to pre 7.0. https://gerrit.libreoffice.org/c/core/+/143250
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/29386030a96f2c8b1c636f4d4bb283109e01de8b tdf#142147 saveas: encrypted docs should default to use password It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Vasily requests no backporting. There apparently are undocumented cases that needed his change. A more appropriate solution than clobbering someone else's workflow will need to be developed for those.
(In reply to Commit Notification from comment #28) > Justin Luth committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 29386030a96f2c8b1c636f4d4bb283109e01de8b > > tdf#142147 saveas: encrypted docs should default to use password > > It will be available in 7.6.0. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. If I'm understanding the fix, it doesn't seem suitable to me. This is what I would regard as an acceptable fix: Making a copy of the password protected file should require the original password but if you want to change the password for a copy you should be able to (so long as you enter the original password to start with). I'm not a power user, so I just Save As for my default. So, I don't want to have to change my password every time that I do that. All I want is to be forced to use my password to open the document and ensure that people can't edit, modify or delete content on my password protected document without at least needing to enter a password to do so. I'm not sure if the earlier version this current fix will revert to on this matter meets my suggested fix but if it doesn't, the fix that I propose is the one that I would like to see implemented. As an aside, I'm not sure if it's possible to prevent someone from copying the password document and pasting that information somewhere else. If it isn't, that would be a welcome security feature too.
Since I can't find an edit post feature, I'll just add to my suggested fix the observation that it should not be possible to delete a password protected file without the requirement that the files password be entered. If it's important enough to require a password to modify a file, it's just as important to have the same measure to prevent the deletion of the file itself.
*** Bug 154970 has been marked as a duplicate of this bug. ***