Bug 70183 - characters £ ì è é ò ç à ° § ù © not accepted in PDF passwords
Summary: characters £ ì è é ò ç à ° § ù © not accepted in PDF passwords
Status: RESOLVED DUPLICATE of bug 50400
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: lowest trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyBeginner, easyHack, topicUI
Depends on:
Blocks:
 
Reported: 2013-10-06 06:47 UTC by cITs
Modified: 2018-08-01 16:19 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description cITs 2013-10-06 06:47:41 UTC 
While trying to export a PDF from LO-Writer, i encountered that the first textfields to set a password to either open the document or to have write access, doesn't accept the letter §. The second textfield, to confirm the typed in password, accepts the character §, leading to a "false password". 

Ways to reproduce:
1.) Select 'Export to PDF' from the File menu dialog.
2.) Navigate to 'Security'-tab.
3.) Typ in character § in the first textfield of each option.

This issue has been present in LibreOffice > 4.1.2.3 (unsure if inherited from OOo)
Comment 1 Mike Kaganski 2013-10-06 08:55:59 UTC 
Reproducible with 3.3.0.4-4.1.2.3 and AOO 4.0.

Actually, a number of characters are not accepted in the first field: I tested § (in Windows, key combination Alt+0167), as well as © (Alt+0169).
Comment 2 tommy27 2014-10-25 07:41:45 UTC 
reproducible under Win7x64 using OOo 3.3.0, LibO 4.3.2.2 and 4.4.0.0.alpha1+
Build ID: 6ba8b7f5eacac969e4781d63718083a05491b1bc
TinderBox: Win-x86@42, Branch:master, Time: 2014-10-24_02:23:51

there are multiple characters not allowed...
here's the list I've found:
£ ì è é ò ç à ° § ù ©

edited summary notes and set version to "inherited from OOo"
Comment 3 Mike Kaganski 2014-10-25 12:38:29 UTC 
Also reproducible with 4.3.2.2 under Ubuntu 14.04.
Comment 4 Peter Maunder 2014-10-25 16:00:03 UTC 
Same problem with 4.3.2.2 and ubuntu 12.04. It looks as if the password has to be US-ASCII (7bit)and not the normal Unicode. The Characters £ ì è é ò ç à ° § ù © etc are in ISO-8859-1 (Western European 8 -bit). Is this a PDF password restriction?
Comment 5 Mike Kaganski 2014-10-25 23:41:52 UTC 
(In reply to Peter Maunder from comment #4)
> Is this a PDF password restriction?

PDF spec (http://www.adobe.com/devnet/pdf/pdf_reference.html) does not impose any restriction on the password string. It references RFC 2898 (https://www.ietf.org/rfc/rfc2898.txt), which itself specifies:

> Throughout this document, a password is considered to be an octet
> string of arbitrary length whose interpretation as a text string is
> unspecified. In the interest of interoperability, however, it is
> recommended that applications follow some common text encoding rules.
> ASCII and UTF-8 [27] are two possibilities. (ASCII is a subset of
> UTF-8.)

So, there seems to be no special reason not to use internationalized characters in passwords. Taking into account that PDF standard provides for 32-byte passwords only, using non-ASCII (multi-byte) may somewhat weaken the security, but this should be up to user (probably with warning).

However, there must be some convention somewhere regarding this, so that different PDF readers could encode passwords coherently. I haven't found this convention yet.

Still, even if there is ASCII-only password restriction, there should be (1) notice in the password dialog (so that user would not enter some characters looking at the keyboard, not at screen, and the absent characters would be unnoticed), and (2) coherent behaviour of both "enter password" and "confirm password" input boxes.
Comment 6 Peter Maunder 2014-10-26 08:37:58 UTC 
(In reply to Mike Kaganski from comment #5)
> Is this a PDF password restriction? No should allow Unicode UTF-8.

I agree with your comments. If it is a genuine restriction the restrictions should be stated clearly on the password panel. If not it appears to be a bug.
Comment 7 QA Administrators 2015-12-20 16:08:27 UTC Comment hidden (obsolete)
Comment 8 Peter Maunder 2016-01-24 16:59:31 UTC 
Version: 5.1.0.2
Build ID: ecd3574d51754b043f865cf5bafee286d24db7cc
CPU Threads: 4; OS Version: Linux 3.13; UI Render: default; 
Locale: en-GB (en_GB.UTF-8)

The problem is still present in 5.1.0.2, for the PDF password entry. However the CONFIRM password field does allow the use of special characters. So whereas only ace is valid  in the password entry field, aceáçé is valid in the password confirmation field. The help entry includes the text 

"Contains a mix of lower-case and upper-case letters, numbers, and special characters." which appears to confirm that it is a bug.
Comment 9 QA Administrators 2017-05-22 13:19:24 UTC Comment hidden (obsolete)
Comment 10 cITs 2017-07-08 14:26:02 UTC 
Issue still exists.
Tested with 5.2.7.2 on Gentoo Base System release 2.3 x86_64
Comment 11 Mike Kaganski 2017-07-08 17:41:15 UTC 
The PDF encryption was implemented here: https://bz.apache.org/ooo/show_bug.cgi?id=12626

Code pointers:
1. Setting the password dialog to only accept ASCII:
> aPwdDialog->AllowAsciiOnly();
in IMPL_LINK_NOARG(ImpPDFTabSecurityPage, ClickmaPbSetPwdHdl, Button*, void) (filter/source/pdf/impdialog.cxx)

2. Using the string encoded as ANSI-1252:
> OString aString( OUStringToOString( i_rPassword, RTL_TEXTENCODING_MS_1252 ) );
in void PDFWriterImpl::padPassword( const OUString& i_rPassword, sal_uInt8* o_pPaddedPW ) (vcl/source/gdi/pdfwriter_impl2.cxx)

3. Code that checks if an allowed character is entered:
void SfxPasswordDialog::ModifyHdl(Edit* pEdit) (sfx2/source/dialog/passwd.cxx)

I am now unsure if it would be good idea to make both fields (password and verification) working identically: if they both filtered user input, then user could not notice that some of characters were rejected, and be sure that the password is as entered; and after that, would discover the password (containing non-1252 characters) be wrong. But anyhow, the code that filters out characters could make visual and audible hints that some characters got filtered (e.g., balloon hints or something).

The other idea (to use UTF-8 encoding, and thus allow any input) looks more appealing.
Comment 12 Mike Kaganski 2017-07-08 18:54:42 UTC 
The relevant information from Adobe is here:
https://forums.adobe.com/thread/831473
https://forums.adobe.com/thread/489152

So, the algorithm used by LibreOffice could in theory allow using any characters, but they would need to be converted to system 8-bit codepage (different for Win and Mac) before using for encryption. Thus, a PDF encrypted with non-ASCII characters would be ~impossible to open on any system with different system locale. Thus, using the ASCII restriction is a good choice.

I tested that encoding the password as utf-8 makes the PDF unopenablw using Adobe Acrobat Reader DC 2017.

The problem here remains only to make this user-visible and documented.
As the easiest solution for those who would like to implement this (as an easyhack), I'd propose to add to the SfxPasswordDialog a (yellow?) label saying something like "Only English letters, numbers other ASCII characters", which were hidden by default, and were made visible in the SfxPasswordDialog::AllowAsciiOnly().
Comment 13 QA Administrators 2018-07-09 02:36:22 UTC Comment hidden (obsolete)
Comment 14 Mike Kaganski 2018-07-09 03:08:27 UTC 
Still repro with Version: 6.1.0.1 (x64)
Build ID: 378e26bd4f22a135cef5fa17afd5d4171d8da21a
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: ru-RU (ru_RU); Calc: CL
Comment 15 Timur 2018-08-01 16:19:32 UTC 
Looks like a dupe of 50400. Please explain if not. 
I'll copy some of Mike's comments there.

*** This bug has been marked as a duplicate of bug 50400 ***