Hey there!
For university I’m often dealing with a bunch of PDFs that all share the same password. Sumatra will remember the password, but only for each individual document, which means I have to re-enter it for each new set of lecture slides.
Is it possible to add a feature that, when opening a new password protected document, automatically tries all previously entered passwords?
Thanks in advance!
Hi @Elch
There is AN OPTION TO STORE PASSWORDS IN THE SumatraPDF-settings.txt FILE
a whitespace separated list of passwords to try when opening a password protected document
(passwords containing spaces must be quoted) (introduced in version 2.4)
DefaultPasswords =
So add a list at the start like this
# For documentation, see https://www.sumatrapdfreader.org/settings3.2.html
DefaultPasswords = 123 "Hello World" "Super user"
MainWindowBackground = #80fff200
...
Note when it next saves settings it will be moved to a default position lower in the file
Thank you so much, you made my day!
Have a great one 
Don’t forget that since the settings file is plain text, anyone with access to it can see the passwords.
@kjk: Just like some archivers perhaps we can have Sumatra too securely cache in RAM any passwords previously entered during the current session only, and try them automatically with any additional password-protected files before displaying the password prompt if required? Of course the cache would be wiped during program exit.
@SumatraPeter and other viewing this request
Good point made is that in this case passwords are shown as plaintext in the whitelist see Default Passwords
I had presumed in this case the user was not worried about those passwords being shown
For each specific file the password can be stored encrypted as discussed in
The OP in this case does not want to re-enter the same password repeatedly for each new set of lecture slides. Thus the only option is to add the password as plain text to DefaultPasswords, because saving passwords encrypted to FileStates\DecryptionKey is a per-file process AFAIK.
The note of caution of course is still valid, because while FileStates\DecryptionKey prevents a third party from knowing the original password (assuming of course that it can’t be retrieved by reverse-engineering whatever the source code does), if that third party has access to the settings file then FileStates\DecryptionKey will still facilitate opening the password-protected file for them.
tl;dr: Common sense dictates that passwords not be saved, in plain text or encrypted form, if you don’t want someone else with access to the settings file to be able to view your protected document.