Versleutelen vs. wachtwoordbeveiligen: wat Protect en Unlock echt doen

Mensen zeggen “een PDF met een wachtwoord beveiligen” en “een PDF versleutelen” alsof het verschillende producten zijn. In het PDF-formaat komen ze uit dezelfde familie van mechanismen: het bestand bevat een /Encrypt-dictionary, en viewers hebben een wachtwoord (of gelijkwaardige inloggegevens) nodig voordat ze de pagina-inhoud leesbaar aan u geven.

Wat “password protect” werkelijk betekent

Een beveiligde PDF is niet slechts een slot in de UI van één app. Lezers die de standaard volgen, weigeren het document te openen tot het juiste open-wachtwoord is opgegeven. Dat is versleuteling van de bestandsinhoud, met een sleutel die zo is afgeleid dat het wachtwoord nodig is om te ontsleutelen.

Protect PDF (POST /api/v1/security/add-password) neemt een wachtwoord dat u kiest en levert een versleuteld bestand dat bij het openen om dat wachtwoord vraagt. Het portalformulier vraagt om één wachtwoordveld. De server versleutelt via qpdf (--encrypt) en gebruikt die waarde als gebruikerswachtwoord (open-wachtwoord); als er via de API geen apart eigenaarswachtwoord wordt meegegeven, gebruikt hij dezelfde tekenreeks voor de eigenaarsrol. De standaardsleutellengte is 256 bits. De tool bewaart uw wachtwoord niet nadat de verwerking klaar is. Raakt u het kwijt, dan blijft het resulterende bestand vergrendeld.

Gebruikerswachtwoord versus eigenaarswachtwoord

PDF-versleuteling onderscheidt van oudsher twee rollen:

• Gebruikerswachtwoord (open-wachtwoord): nodig om het document überhaupt te openen en te bekijken.
• Eigenaarswachtwoord (rechten): wordt vaak gebruikt om beperkingen voor printen of wijzigen in te stellen terwijl iemand het bestand toch kan openen met het gebruikerswachtwoord (of met een leeg open-wachtwoord, afhankelijk van hoe het bestand is gemaakt).

Dat zijn concepten uit het formaat, geen marketinglabels. Veel alledaagse processen om “deze PDF te vergrendelen” zetten alleen een open-wachtwoord. Printen of bewerken beperken zonder het openen te blokkeren is een verhaal over rechten dat de eigenaarsrol gebruikt; het is makkelijk te verwarren met “het bestand opent niet”.

Op PDF123 vraagt het Protect-formulier om één wachtwoord en behandelt dat als het open-wachtwoord dat nodig is om het bestand te bekijken. Unlock heeft datzelfde bekende wachtwoord nodig om te ontsleutelen. Gevorderde API-aanroepers kunnen ownerPassword, keyLength, canPrint en canModify meegeven bij add-password; het browserformulier biedt die opties niet.

Wat Unlock doet (en niet doet)

Remove Password (POST /api/v1/security/remove-password) verwijdert bestaande wachtwoordversleuteling wanneer u het juiste huidige wachtwoord opgeeft. Pagina's, fonts en opmaak blijven hetzelfde; alleen de versleutelingsvereiste verdwijnt.

Het herstelt, raadt of kraakt geen vergeten wachtwoord. Kent u het wachtwoord niet, dan verzint Unlock er geen. Repair verwijdert de versleuteling evenmin: als Get Info Encrypted: true rapporteert, moet u eerst ontgrendelen en daarna bewerken.

Wanneer u welke gebruikt

Zowel Protect als Unlock draaien server-side zonder account op het cataloguspad. Versleutelen maakt het bestand niet kleiner; Compress is een aparte taak met streamrecompressie en heeft nog steeds een ontgrendelde (of nooit versleutelde) PDF nodig. OCR, tabelexport en de meeste bewerkingen hebben eveneens eerst toegang tot onversleutelde inhoud nodig: ontgrendel met een bekend wachtwoord en gebruik daarna de andere tool.

Bewaar wachtwoorden buiten de PDF (wachtwoordmanager, geheimenkluis). Zet het open-wachtwoord niet in dezelfde e-mail als de bijlage; dat ondermijnt de beveiliging. Voor dezelfde taken via HTTP, zie Developers.