Bug 43452 - Long Password fails for file saving LibreOffice CALC file
Summary: Long Password fails for file saving LibreOffice CALC file
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.4.2 release
Hardware: x86 (IA32) All
: medium major
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0 target:7.0.0.1
Keywords:
: 43451 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-12-01 21:01 UTC by C. Andrews Lavarre
Modified: 2020-08-01 14:04 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description C. Andrews Lavarre 2011-12-01 21:01:12 UTC
LibreOffice 3.4.2 
OOO340m1 (Build:1206)
OpenSuSE 11.4 KDE 4.6

Sorry, something sent this incomplete before...

I try to save a CALC file as something with the SAVE WITH PASSWORD option clicked. I used a strong password:

Abbcd@Efghi!Klmn

(16 characters, alphanumeric and symbol mixed)

I enter it twice and it saves successfully, but then on reopening the file it claims I do not have the correct password.

However, if I use a shorter password:

Abcdefg@Hijlm

(13 characters) 

It works.

So there seems to be some limit on the length of the allowable password...

Please keep me informed on any progress,

alavarre@gmail.com

Cheers, Andy Lavarre
Comment 1 C. Andrews Lavarre 2011-12-01 21:30:05 UTC
OK, I have experimented further.

If I use a 15-character password to save the file it works.

If I use a 16-character password to save the file it also works, insofar as it allows saving.

But when I try to open the 16-character password file with the 16-character password it fails.

HOWEVER, if I only insert the first 15 characters of the password then the file opens correctly.

So there is a bug in the password parsing: If you offer more than 15 characters it apparently wraps around, corrupting the offered password, rather than just dropping all characters after the fifteenth.

Interesting stuff, thanks.

Keep me informed.

The workaround for now is to limit passwords to 15 characters.

Cheers, Andy Lavarre
alavarre@gmail.com
Comment 2 tester8 2012-01-12 06:15:41 UTC
NOT reproduced with

LOdev 3.5.0beta2 
4ca392c-760cc4d-f39cf3d-1b2857e-60db978
Ubuntu 10.04.3 x86
Linux 2.6.32-37-generic Russian UI

Can you try with 3.5.0beta2?
Comment 3 Jean-Baptiste Faure 2012-01-28 23:59:18 UTC
@reporter: if I compare with bug 43451, it is not clear in which format you saved your file. ODS or XLS ?
I do not reproduce with ODS in LO 3.5.0 rc2+ under Ubuntu 11.10.

Best regards. JBF
Comment 4 C. Andrews Lavarre 2012-01-29 09:16:25 UTC
Jean-Baptiste good afternoon. 

I have just checked and confirmed this on LibreOffice 3.4.4 
OOO340m1 (Build:1403) under openSUSE 12.1.

It occurs when saving a file as XLS. You can save the file with a password of sixteen or more characters without incident, however when you try then to open it with the same >= 16 character password it complains that the password is incorrect.

However, if you only enter the first fifteen characters then it opens correctly.
=====
You are correct that this does not occur if the file has been saved as an ODS. But it does occur if you save as an XLS.

Kind regards, Andy
Comment 5 Jean-Baptiste Faure 2012-01-29 09:33:38 UTC
*** Bug 43451 has been marked as a duplicate of this bug. ***
Comment 6 Jean-Baptiste Faure 2012-01-29 09:42:35 UTC
Ok, reproduced with LO 3.5.0 rc2+ too (LibreOffice 3.5.0rc2+ Version ID : 20ec7c1-ed94322-5cd2479-2386a41-138191a)

Best regards. JBF
Comment 7 A (Andy) 2014-09-20 19:19:49 UTC
Still reproducible with LO 4.3.1.2 (Win 8.1)

If you try to type a password longer than 15 characters it doesn't work.  This is user-unfriendly because the user gets no information in the password dialog box that a password longer than 15 characters is not possible.  It is not mentioned in the note below.
Only if you insert a password longer than 15 characters with copy&paste you get an information: 'The inserted text exceeded the maximum length of this text field. The text was truncated.'

I don't think that a maximum password length of 15 characters is useful and at least the user needs to be informed.  
All in all, there should be no length limitation or at least a much longer one.
Comment 8 DN 2015-02-11 11:42:19 UTC
* LO limits password *entry* to 15 characters when *saving* as (at least) DOCX or XLSX. There is no visual indicator that further characters are being ignored, other than that no more asterisks appear.
* LO does *not* limit password entry length when *decrypting* DOCX/XLSX files.
* Office 2013 (at least) doesn't limit passwords to 15 characters. Saving with a 20-character password in Office 2013, it is successfully decrypted with the same 20 characters using LO. Decryption fails when only entering the first 15 characters, so LO does seem to use the full length for decryption.
* It seems there was a limit in *earlier* versions of Office to passwords of 15 characters or fewer, for example: http://support.microsoft.com/kb/KbView/291457

At least two things are needed here:

* If LO is limiting password entry on OOXML to 15 characters, it needs to actively alert the user. Otherwise the user may enter a long password, not notice that it has been truncated, and be unable to open it with the password they *typed*. This is exactly what happened to me, and I was only able to regain access by experimenting to find the cause.
* Compatibility of >15-character-passworded OOXML documents with earlier OOXML-capable versions of Office (2007, 2010). If 2007 and 2010 are long-password-capable, the artificial limit on OOXML password creation length needs to be removed from LO (assuming it is just a deliberate truncation on entry).
Comment 9 A (Andy) 2015-03-07 15:50:35 UTC
> At least two things are needed here:
> 
> * If LO is limiting password entry on OOXML to 15 characters, it needs to
> actively alert the user. Otherwise the user may enter a long password, not
> notice that it has been truncated, and be unable to open it with the
> password they *typed*. This is exactly what happened to me, and I was only
> able to regain access by experimenting to find the cause.

This is no longer reproducible with LO 4.4.1.2, Win 8.1. (see also bug 65492)


> * Compatibility of >15-character-passworded OOXML documents with earlier
> OOXML-capable versions of Office (2007, 2010). If 2007 and 2010 are
> long-password-capable, the artificial limit on OOXML password creation
> length needs to be removed from LO (assuming it is just a deliberate
> truncation on entry).

This would be a good enhancement.
Comment 10 tommy27 2016-04-16 07:26:35 UTC Comment hidden (spam)
Comment 11 Jean-Baptiste Faure 2016-04-17 10:29:48 UTC
Now (LO 5.1.3.0.0+) there is a warning message when you try to paste a string password longer than 15 characters. If you type the password the exceeding characters are not accepted (the *** string does not grow anymore).

Closing as WorksForMe as I do not know which commit added the warning message.

Best regards. JBF
Comment 12 Justin L 2020-06-16 17:18:48 UTC
(In reply to Jean-Baptiste Faure from comment #11)
> Now (LO 5.1.3.0.0+) there is a warning message when you try to paste a
> string password longer than 15 characters.
Actually, it isn't "Now". That has been true since LO 3.5 at least, and was mentioned in comment 7 already.

>  If you type the password the
> exceeding characters are not accepted (the *** string does not grow anymore).
That also was already true.

NOW, in LO 6.1, the warning during paste is gone, because of commit da9aa49f360c1351f5b5ce8bcf4a9df2db8c4f15
Author: Caolán McNamara on Thu Mar 22 09:32:51 2018 +0000
    weld PasswordToOpenModifyDialog


Caolán: if you decide to fix this, you might also want to consider a way to notify people who TYPE a long password as well as those who PASTE a long password.

I confirm that the maximum password save length is still 15 characters, and that if you try to open it by pasting the longer phrase you tried to save with, it won't work.
Comment 13 Justin L 2020-06-16 17:25:59 UTC
Oh, and also consider the same fixes for .doc - which apparently never had that. See bug 65492 for the .doc case.

I confirmed that xlsx and docx can handle longer passwords.  (I tested with 32 chars.)
Comment 14 Caolán McNamara 2020-06-17 11:20:24 UTC
"NOW, in LO 6.1, the warning during paste is gone"

Its still present under gen, that dialog is a feature of the vcl Edit that GtkEntry doesn't have. Instead GtkEntry just fires gtk_widget_error_bell on the short paste which traditionally dinged, though (I think) the audible bell has fallen into disuse so in practice nothing dings. Using...

gsettings set org.gnome.desktop.wm.preferences visual-bell true

shows a flash when it hits the char limit so the indication is fired, just nothing reaches the user by default. So I guess we need an indicator of our own.
Comment 15 Caolán McNamara 2020-06-17 13:29:13 UTC
Some things have changed since the original report so its all a bit murky at this point. But worth noting:

When there's a limit to the length of the password it is due to there being a limit in the file format being saved to and there's no way around that a limit exists. The traditional limit in the binary word/excel file formats was 15 (that there seems to be some change to that in MSOffice can be left to the specific bug 65492)

There may have been a time in the past where we were enforcing that doc/xls password length limit for the docx/xlsx case, but that doesn't seem to be the case anymore. There isn't a limit for those at the moment that I can see, not is there for our own od[s|t] format.

Seeing as there is a limit the only thing I can see to do is indicate when the limit has been reached.
Comment 16 Justin L 2020-06-17 13:52:37 UTC
(In reply to Caolán McNamara from comment #15)
> Seeing as there is a limit the only thing I can see to do is indicate when
> the limit has been reached.
Yes. I think that is exactly what OP was asking for. Thanks for taking this on.
Comment 17 Commit Notification 2020-06-17 14:38:49 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a81d7c4e0379a021664f8f6c5e9032a47fcf61d6

tdf#43452 indicate when maximum password length has been reached

It will be available in 7.1.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.
Comment 18 Caolán McNamara 2020-06-17 14:42:35 UTC
indicator text now appears when the password max length has been reached, in the same vein as the "Search key not found" indicator in the search bar
Comment 19 Commit Notification 2020-06-17 14:57:56 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/4331e659b71e303f92a62db0dd3b908a67b733b2

tdf#43452 indicate when maximum password length has been reached

It will be available in 7.0.0.1.

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.
Comment 20 Justin L 2020-06-19 18:19:19 UTC
Looks good.
Tested in gen (both methods of notification work - and that is fine).
Tested in .doc and .xls - alert works for both pasting and typing. Nice.
Tested with .docx - long password is allowed.  Perfect.

This does nothing to alert about password length when actually opening the file. (That's OK - out of scope and conceivably a security concern.)
Comment 21 Narax Smith 2020-08-01 10:40:05 UTC Comment hidden (spam)