An encrypted ZIP file can have two correct passwords here’s why – BleepingComputer

Password-protected ZIP archives are common means of compressing andsharing sets of filesfrom sensitive documents to malware samples to even malicious files (i.e. phishing "invoices" in emails).

But, did you know it is possible for an encrypted ZIP file to have two correct passwords, with both producing the same outcome when the ZIP is extracted?

Arseniy Sharoglazov, a cybersecurityresearcher at Positive Technologies shared over the weekend a simple experiment where he produced a password-protected ZIP file called x.zip.

The passwordSharoglazov picked for encrypting his ZIP was a pun on the 1987 hitthat's become a popular tech meme:

Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You

But the researcher demonstrated that when extracting x.zipusing a completely differentpassword, he receivedno error messages.

In fact, using the different passwordresulted in successful extraction of the ZIP, with original contents intact:

pkH8a0AqNbHcdw8GrmSp

BleepingComputer was able to successfully reproduce the experiment using different ZIP programs. We used both p7zip (7-Zip equivalent for macOS) andanother ZIP utility calledKeka.

Like the researcher's ZIP archive, ours was created with the aforementioned longer password, and with AES-256 encryption mode enabled.

While the ZIP was encrypted with the longerpassword, using either password extracted the archive successfully.

Responding toSharoglazov'sdemo, a curious reader,Rafaraised an important question, "How????"

Twitter userUnblvrseems to have figured out the mystery:

When producing password-protected ZIP archives with AES-256 mode enabled, the ZIPformat uses the PBKDF2 algorithm andhashes the passwordprovided by the user, ifthepassword is too long. By too long, we mean longer than 64 bytes (characters), explains the researcher.

Instead of the user's chosen password (in this case "Nev1r-G0nna-G2ve-...")this newly calculatedhash becomes the actual password to the file.

When the user attempts to extract the file, and enters apassword that is longer than 64 bytes ("Nev1r-G0nna-G2ve-..."), the user's input willonce again be hashed by the ZIP application and compared against the correct password (which is now itself a hash). Amatch would lead to a successful file extraction.

The alternative password used in this example("pkH8a0AqNbHcdw8GrmSp") is in fact ASCII representation of the longer password's SHA-1 hash.

SHA-1 checksum of "Nev1r-G0nna-G2ve-..." =706b4838613041714e62486364773847726d5370.

This checksum when converted to ASCII produces:pkH8a0AqNbHcdw8GrmSp

Note, however, that when encrypting or decrypting a file,the hashing process only occurs if the length of the password is greater than 64 characters.

In other words,shorter passwords will not be hashed at either stageof compressing or decompressing the ZIP.

This is why when picking the long "Nev1r-G0nna-G2ve-..." string as the password at the encryption stage, the actualpassword being set by the ZIP program is effectively the (SHA1) hash of this string.

At the decryption stage, if you were to enter "Nev1r-G0nna-G2ve-...," it will be hashed and compared against the previously stored password (which is the SHA1 hash). However, entering the shorter "pkH8a0AqNbHcdw8GrmSp" password at the decryption stage will have the application directly compare this value to the stored password (which is, again the SHA1 hash).

TheHMAC collisions subsection of PBKDF2 on Wikipedia provides some more technical insight to interested readers.

"PBKDF2 has an interesting property when using HMAC as its pseudo-random function. It is possible to trivially construct any number of different password pairs with collisions within each pair,"notes the entry.

"If a supplied password is longer than the block size of the underlying HMAC hash function, the password is first pre-hashed into a digest, and that digest is instead used as the password."

But, the fact that there are nowtwo possible passwords to the same ZIP does not represent a security vulnerability,"as one still must know the original password in order to generate the hash of the password," the entry further explains.

An interesting key aspect to note here is, ASCII representationsof every SHA-1 hash need not be alphanumeric.

In other words,let's assume we had chosen the following password for ourZIP file during this experiment.The password is longerthan 64 bytes:

Bl33pingC0mputer-Sh0w-M3-H0W-t0-pR0Duc3-an-eNcRyPT3D-ZIP-File-in-the-simplest-way

Its SHA-1 checksum comes out to be:bd0b8c7ab2bf5934574474fb403e3c0a7e789b61

And the ASCII representation of this checksum looks like a gibberish set of bytesnot nearly elegant as the alternative password generated by the researcher for his experiment:

BleepingComputer askedSharoglazov how was he able to pick a password whose SHA-1 checksum would be such that its ASCII representation yields a clean, alphanumeric string.

"That's why hashcat was used," the researcher tells BleepingComputer.

By using a slightly modified version of the open source password recovery tool, hashcat, the researcher generated variations of the "Never Gonna Give You Up..." string using alphanumeric characters until he arrived at a perfect password.

"I tested Nev0r, Nev1r, Nev2r and so on... And I found the password I need."

And, that'showSharoglazov arrived at a password that roughly reads like "Never Gonna Give You Up...," but the ASCII representation of itsSHA-1 checksum is oneneatalphanumeric string.

For most users, creating a password-protected ZIP file with a choice of their password should be sufficient and that is all they would need to know.

But should you decide to get adventurous, this experiment providesa peek into one of the many mysteries surroundingencrypted ZIPs, like having two passwords to your guarded secret.

Read more here:
An encrypted ZIP file can have two correct passwords here's why - BleepingComputer