This article was first published at ITK SECURITY.
Last updated 1 year ago by Patrick Ruppelt
Reading time: 8 minutes
Cracking a password-protected PDF or ZIP file usually takes only a few seconds with the right tools. A fact that banks, doctors and many other public authorities are often not aware of.
What banks mean by "safe
Sensitive data should not be exchanged by e-mail. This is well known. There are far better options, such as digital data rooms. We offer our customers such rooms on our own servers in our data centre, where every file is stored in encrypted form and common methods for "cracking" passwords are not possible. To name just one very simple technique, for example because you are locked out and blocked after three failed attempts. As is so often the case, there is of course a "catch": these systems cost money. Security is not available for free.
Unfortunately, many service providers, from whom one should actually be able to expect something different, still take a different view. Banks, for example.
A common misconception here is that protecting a file with a password means that only the person who has the password can open the file. This is very popular with PDF files and ZIP archives (I am thinking of an INI letter from the bank), but password protection is also often used with Word files or packed ZIP files.
With a correspondingly complex password, this is certainly secure, but not if, as is common in banks, simply a five-digit postcode is used as a password. As a simple example shows, it is a fallacy to believe that something like this would be secure.
The test setup
For my test, I created a PDF file and encrypted it with the simple password 'test'. In the file view, it is visually indistinguishable from an ordinary PDF file without encryption. Every common computer can open the file, print it etc.
When attempting to open the file, the user receives a password prompt. Without this, the file cannot be opened:
Procedure for cracking the password
This article is only intended to illustrate how easy it is to crack such a password with the right tools. We do not give advice here on how to "hack". Therefore, parts of the necessary commands have been made unrecognisable.
I do not want to call on anyone to get into mischief, but only to point out the problem as such in order to raise awareness.
The procedure is as simple as it is effective. I now use my notebook to try to open the file in a loop. Each time the file asks for the password, I give it an automatically generated password.
First, dictionary words are used. This also explains why it is always advised not to use real words or even names as passwords.
If none of my passwords, which were automatically tested from dictionaries, are successful, I continue with a so-called "brute force" attack. Here, all conceivable or possible passwords are simply tried out. First everything from a to Z, then aa, ab, ac, ad, ... etc. as well as letters, numbers and special character combinations. After all, it has to be a password of some kind, so you are guaranteed to find a working password at some point through trial and error.
The practical test using the example
Technically, it looks like this:
The only limiting factor is the processing power I have available. The processor performance goes up to 100% on the one core on which I run the programme. If I want to do the whole thing on a large scale, I distribute the load over all eight processors available. This would allow my notebook to test around 370,000 passwords per second (!).
A bit of mathematics
For this simple test, one processor core is enough for me. In about 1.5 minutes, the correct password was found by trial and error.
And this also explains why it is recommended to avoid particularly short passwords.
Let's think of a character set of allowed password elements:
- 26 letters: a to z (lower case)
- 26 letters: A to Z (capital letters)
- 7 Umlauts and sharp S: ä, ö, ü, Ä, Ö, Ü, ß
- 19 Special characters: . , - _ ; : ! " § $ % & / ( ) = ? # + *
This results in exactly 78 valid possibilities for each character. This means that, mathematically, there are
- Password with 1 digit only 78 possibilities,
- Password with 2 digits 78^2 = 6,084 possibilities,
- Password with 3 digits 78^3 = 474,552 possibilities,
- Password with 4 digits 78^4 = 37,015,056 possibilities,
- Password with 5 digits 78^5 = 2,887,174,368 possibilities,
- Password with 6 digits 78^6 = 225,199,600,704 possibilities etc.
It is easy to see that the complexity and the possible passwords to try out increase quite considerably with each additional digit of the password.
Conclusion
Nevertheless, this changes nothing at all when cracking passwords, except for the time factor. Whereas my notebook needs less than two minutes for four digits, we're talking about several hours for a few more. With enough computing power and/or enough time, I can still crack any password and do nothing more than wait for my automatic system to spit out the right password. The only remedy is a sufficiently complex password, which would then require an automated procedure to be on the safe side.
Therefore, manual file encryption is generally not considered secure and is not recommended for sending sensitive documents, e.g. by e-mail.
Legal background
When "cracking" passwords, it is essential to observe the legal framework. The deliberate circumvention of protective mechanisms is usually punishable by law. In this context, we recommend further reading of the corresponding article of the Verlag für Rechtsjournalismus GmbH linked here1).