An encrypted ZIP archive can have two valid passwords

August 20, 2022. Arseniy Sharoglazov, a developer and pentester from Positive Technologies, explained why a ZIP file encrypted with a very long password using the AES-256 encryption algorithm can eventually be opened using two different, but correct passwords.

You can check it like this: create a ZIP file with the command "7z a x.zip /etc/passwd -mem=AES256 -p" with the password "Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You" and unpack this archive using the password "pkH8a0AqNbHcdw8GrmSp".

Habr magazine checked that on Linux Mint in Zip utility with default settings, this situation is reproduced. Also, two passwords open one file using 7zip, p7zip and Keka utility. The experts explained that Zip uses the PBKDF2 password-based key generation standard. That means it hashes the input if it is too large. This hash (in raw bytes) is that second password we talk about, but actually it is the ASCII form of SHA-1 hash. You see, when you encrypt or decrypt a file, if the password length exceeds 64 characters, the hashing process begins. If password is shorter it will not be hashed during the compression stage or during the decompression stage of the Zip archive.

For example, you have a password "Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You". It`s hash is "706b4838613041714e62486364773847726d5370". Convert it to ASCII and you will have the second password "pkH8a0AqNbHcdw8GrmSp". When you enter this shorter password, Zip application compares this value with the previously stored long password as its SHA1 hash. The point is, ASCII representation of each SHA-1 hash is not necessarily alphanumeric. Sharoglazov admitted that he had to sort through several hundred million long password options using the hashcat utility to end up with a simple second password with only alphanumeric characters without gibberish in the form of non-printable characters.