Bug 97086 - Encrypting OOXML files truncates password to 15 characters
Summary: Encrypting OOXML files truncates password to 15 characters
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
5.0.4.2 release
Hardware: All All
: medium major
Assignee: Eike Rathke
URL:
Whiteboard: interoperability target:6.5.0 target:...
Keywords: filter:ooxml
: 109175 132020 138308 (view as bug list)
Depends on:
Blocks: XLSX Password-Protected
  Show dependency treegraph
 
Reported: 2016-01-12 22:33 UTC by alex
Modified: 2020-11-18 11:23 UTC (History)
9 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 alex 2016-01-12 22:33:36 UTC
Opening a XLSX file or 
Saving as XLSX file and tick the "Save with password" option.
Entering the password without watching the input line twice.
Document is now encrypted, but the password will fail if it consists of more than 15 characters. Copy pasting a more than 15 character password will yield a notice that the password was truncated. What's missing is a notification to this limit, better yet get rid of the limit. Excel 2010 encrypts XLSX files woth passwords above 15 characters and LibreCalc can open them fine, too. So why the limitation in regard to password length?
Comment 1 FutureProject 2016-01-13 01:25:51 UTC
Thank you for reporting this issue.

I can reproduce and confirm the described behaviour.

Windows 10 Pro, Version 1511 (OS Build 10586.36)
Version: 5.0.4.2 Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78
Locale: de-DE (de_DE)

To reproduce:
1. Create new Calc document
2. File -> Save As
3. Set "Save as Type" to XLSX
4. Tick "Save with Password"
5. Click Save
6. The appearing password textboxes have a 15 character limit and give no visual or audible warning when addidional keys are pressed

In contrast, saving in ODS file format does not have a 15 character limit, which could be confusing when this behaviour is expected. Since it can lead to data becoming inaccessible I'm both setting this issue to NEW and elevating it to MEDIUM/CRITICAL.
Comment 2 Luke Picciau 2016-01-13 01:32:25 UTC
If there is going to be a limit LO should let the user keep typing but show a message that the password is too long and not let them save until its been shortened rather then just not taking in any more input which the user might not notice.

Also set OS to all because it affects linux too.
Comment 3 Joel Madero 2016-01-13 02:57:21 UTC
This should be checked to find out if it's a regression. Also, sorry for the noise but I'm lowering to Major.

Reason: Critical really should be kept for the worst bugs that affect the project. Worst means, serious data loss/crashes for a *significant portion of our user base.*" Although this might lock out data - this would be in incredibly rare cases....when? Well: (1) when a user password protects which is already in a very small minority of our user base; and then (2) when that password is >15 characters long; and finally (3) when the user isn't aware of this limitation. A relatively fast search of the bugs will come up with this hit....if it's not a regression, proof of how rare it is comes with the fact that it has never been reported before :)

By default critical and major bugs go to "high" but I'm leaving as "medium" due to the above rationale - the very small number of potentially affected users means lower priority in an objective standard.
Comment 4 Katarina Behrens (Inactive) 2016-01-21 11:16:01 UTC
No regression, it's been like this since the beginning of time. 

There's indeed 15 char length limit on passwords in LO, restricted to MSO formats. I can't quite see why as it's impossible to search commit history so far back into the past. 

Likely because of this: https://msdn.microsoft.com/en-us/library/dd772916%28v=office.12%29.aspx It looks like such limit used to exist in binary MSO formats (.doc, .xls)

Couldn't find any info on password limits in OOXML standard, just that this 15 char limit exists in MS Excel on Mac platform: https://support.office.com/en-us/article/Require-a-password-to-open-or-modify-a-workbook-10579f0e-b2d9-4c05-b9f8-4109a6bce643 probably independent of file format.
Comment 5 QA Administrators 2017-03-06 14:13:30 UTC Comment hidden (obsolete)
Comment 6 Buovjaga 2017-08-11 17:36:50 UTC
*** Bug 109175 has been marked as a duplicate of this bug. ***
Comment 7 [REDACTED] 2018-05-13 13:00:45 UTC
See also MR: https://gerrit.libreoffice.org/#/c/54193/
Comment 8 [REDACTED] 2018-06-09 16:42:02 UTC
I've got no feedback for merge request, so I'm not working on this issue anymore.
Comment 9 Eike Rathke 2018-08-25 16:24:29 UTC
Feedback was given in Gerrit by Mike on May-22 but noreply+66619/redacted didn't follow-up on the comments.
Comment 10 QA Administrators 2019-10-26 02:09:56 UTC Comment hidden (obsolete)
Comment 11 Asher 2019-11-08 19:31:19 UTC
After running afoul of this in 6.2.???? I redownloaded 6.3.3.2 (current most recent) and retested. OOXML still has this limit with no warning or other information about what's going on. Just silently continues on truncating a password to 15 characters if you're not paying enough attention.
Comment 12 Eike Rathke 2019-11-29 23:41:28 UTC
Fwiw, versions 6.1 and later at least visually and audibly (with a short beep) notify about the truncation and do not accept more characters.

Taking.
Comment 13 Commit Notification 2019-11-30 01:51:47 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

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

Resolves: tdf#97086 Allow "unlimited" password length for OOXML encryption

It will be available in 6.5.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 14 Eike Rathke 2019-11-30 01:56:12 UTC
Pending https://gerrit.libreoffice.org/84100 for 6-4
Comment 15 Commit Notification 2019-11-30 03:05:42 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/8bf39e6cfd988089bd0eab0958c96f8fc3413b9d

Resolves: tdf#97086 Allow "unlimited" password length for OOXML encryption

It will be available in 6.4.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 16 Aron Budea 2020-04-10 11:03:41 UTC
*** Bug 132020 has been marked as a duplicate of this bug. ***
Comment 17 Mike Kaganski 2020-11-18 11:23:21 UTC
*** Bug 138308 has been marked as a duplicate of this bug. ***