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

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?

@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

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

*** Bug 43451 has been marked as a duplicate of this bug. ***

Ok, reproduced with LO 3.5.0 rc2+ too (LibreOffice 3.5.0rc2+ Version ID : 20ec7c1-ed94322-5cd2479-2386a41-138191a)

Best regards. JBF

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.

* 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).

> 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.

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

(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.

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.)

"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.

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.

(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.

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.

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

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.

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.)