Encrypted zips (AES256) are easy to break:
- generate an encrypted zip (alt+F5, Encrypt (only tried with EAS256))
- go to Sync. dirs
- try & sync the encryped zip
- I will ask pw
- use a random input
- whatever the next message is: confirm with the same random input
- you're in!
And actually, the pw of the zip is changed to the random input
Please update this rather large hole in security
encrypted ZIPs unsafe -> easy to decrypt without password
Moderators: Hacker, petermad, Stefan2, white
Hello, jazzz.
No, this is not a security vulnerability, but a misunderstanding on your side.
When you created the AES encrypted ZIP file, you had to specify the encryption password twice.
In the second password edit box there is a tickbox below the password.
You will have enabled the tickbox [x] Remember (until program is closed or minimized)
This is why you can start synchronizing without having to enter the ZIP password again.
Try the same steps which you give, but make sure that the "remember" tick box is unticked (disabled) when creating the AES encrypted ZIP file.
You will not be able to synchronize anything without entering the valid password first.
--
You may also retry your own steps and tick the "remember" option. But minimize T.C. and restore the application window before trying to synchronize.
You should be asked for the password. And only the correct password will grant access to the content of the encrypted ZIP file.
Bestr regards,
Karl
No, this is not a security vulnerability, but a misunderstanding on your side.
When you created the AES encrypted ZIP file, you had to specify the encryption password twice.
In the second password edit box there is a tickbox below the password.
You will have enabled the tickbox [x] Remember (until program is closed or minimized)
This is why you can start synchronizing without having to enter the ZIP password again.
Try the same steps which you give, but make sure that the "remember" tick box is unticked (disabled) when creating the AES encrypted ZIP file.
You will not be able to synchronize anything without entering the valid password first.
--
You may also retry your own steps and tick the "remember" option. But minimize T.C. and restore the application window before trying to synchronize.
You should be asked for the password. And only the correct password will grant access to the content of the encrypted ZIP file.
Bestr regards,
Karl
MX Linux 21.3 64-bit xfce, Total Commander 11.50 64-bit
The people of Alderaan keep on bravely fighting back the clone warriors sent out by the unscrupulous Sith Lord Palpatine.
The Prophet's Song
The people of Alderaan keep on bravely fighting back the clone warriors sent out by the unscrupulous Sith Lord Palpatine.
The Prophet's Song
Hi, jazzz.
Second misunderstanding:
When resynchronzing with the encrypted ZIP file you can specify a new password for files which you add to the encrypted ZIP file.
Means:
All files inside the encrypted ZIP file will be accessible using the first password, EXCEPT those for which you have given the new password when adding them.
Result:
You can have an encrypted ZIP file where you have to specify different passwords for different files inside the ZIP File in order to access the content of the archived files.
In no case, however, you will be able to access any file without knowing the right password.
Regards,
Karl
Second misunderstanding:
When resynchronzing with the encrypted ZIP file you can specify a new password for files which you add to the encrypted ZIP file.
Means:
All files inside the encrypted ZIP file will be accessible using the first password, EXCEPT those for which you have given the new password when adding them.
Result:
You can have an encrypted ZIP file where you have to specify different passwords for different files inside the ZIP File in order to access the content of the archived files.
In no case, however, you will be able to access any file without knowing the right password.
Regards,
Karl
MX Linux 21.3 64-bit xfce, Total Commander 11.50 64-bit
The people of Alderaan keep on bravely fighting back the clone warriors sent out by the unscrupulous Sith Lord Palpatine.
The Prophet's Song
The people of Alderaan keep on bravely fighting back the clone warriors sent out by the unscrupulous Sith Lord Palpatine.
The Prophet's Song
jazzz,
ZIP archives do not support encrypting archive listing, so you can always add new files or delete existing ones or overwrite existing files and encrypt new ones with new password.
And, as karlchen said, every file can have its own password, and it is not a security hole because you still can't read old files encrypted with another password.
ZIP archives do not support encrypting archive listing, so you can always add new files or delete existing ones or overwrite existing files and encrypt new ones with new password.
And, as karlchen said, every file can have its own password, and it is not a security hole because you still can't read old files encrypted with another password.
Sorry, it's not the tickbox..
But my description was not 100% clear, let me explain in more detail:
- I get a set of files in a dir -> create the encrypted zip (pw "asd" )
- I change dir contents in the left pane (add some files)
- in the right pane I open the zip (no pw asked)
- using Sync dir, I get "pw required! error unpacking (wrong pw?)"
- I use "q" as pw
- I re-enter "q" as pw
- content is synced!
Please try harder, the above is my usual workflow. After testing now with a new zip and new data, the same happened.
And more funny stuff. If I add files in the encr. zip using a 3rd new random pw "z" (which means anyone can compromise my zipfile!!), I can only copy it out with that same 3rd pw "z".
But in Sync dir., I can copy the file out of the zip with the old pw ("q"). But it get's todays timestamp, gets corrupted (an unreadble pdf in this case), and of course, in the next sync it wants to enter the zip since it is considered to be a more recent file..
So please try again with a dir + files in one pane and an encrypted zip in the other. All funny things are possible, and certainly not secure.
It's not new, I saw this half a year ago..
But my description was not 100% clear, let me explain in more detail:
- I get a set of files in a dir -> create the encrypted zip (pw "asd" )
- I change dir contents in the left pane (add some files)
- in the right pane I open the zip (no pw asked)
- using Sync dir, I get "pw required! error unpacking (wrong pw?)"
- I use "q" as pw
- I re-enter "q" as pw
- content is synced!
Please try harder, the above is my usual workflow. After testing now with a new zip and new data, the same happened.
And more funny stuff. If I add files in the encr. zip using a 3rd new random pw "z" (which means anyone can compromise my zipfile!!), I can only copy it out with that same 3rd pw "z".
But in Sync dir., I can copy the file out of the zip with the old pw ("q"). But it get's todays timestamp, gets corrupted (an unreadble pdf in this case), and of course, in the next sync it wants to enter the zip since it is considered to be a more recent file..
So please try again with a dir + files in one pane and an encrypted zip in the other. All funny things are possible, and certainly not secure.
It's not new, I saw this half a year ago..
I missed your response of 10:55 am
I'm not happy with people being able to enter my zips, but lets consider that a feature.
I still dispute your statement:
"In no case, however, you will be able to access any file without knowing the right password. "
I can, without hacking, just by using Sync dir.
- Make a word file
- Make sure that exact file is already in the encrypted in the zip!
- Try updating the file (open in Word, edit, save).
- Sync the file with the encrypted zip using a fantasy pw.
It will override the original file in the zip..
What happens in my case: ALL files are updated in the dir. So after syncing with the zip, if I use my fantasy pw "q", that effectively means ALL files now have pw. "q" in the zip.
Making the original pw. useless: I changed the pw. to "q" for all files, without using the original pw.
I do not like this feature since anyone can ruin my zip and change the pw in the process
I'm not happy with people being able to enter my zips, but lets consider that a feature.
I still dispute your statement:
"In no case, however, you will be able to access any file without knowing the right password. "
I can, without hacking, just by using Sync dir.
- Make a word file
- Make sure that exact file is already in the encrypted in the zip!
- Try updating the file (open in Word, edit, save).
- Sync the file with the encrypted zip using a fantasy pw.
It will override the original file in the zip..
What happens in my case: ALL files are updated in the dir. So after syncing with the zip, if I use my fantasy pw "q", that effectively means ALL files now have pw. "q" in the zip.
Making the original pw. useless: I changed the pw. to "q" for all files, without using the original pw.
I do not like this feature since anyone can ruin my zip and change the pw in the process
Hello, jazzz.
You have created an encrypted ZIP file named encrypted.zip.
Password for all files inside the ZIP file is ASD, as you explained.
If you had enabled the [x] Remember (until program is closed or minimized) option, when confirming the password ASD, then T.C. will remember and use the password ASD as long as
+ you do not close T.C.
+ you do not minimize T.C.
This means you will be able to access the content of any file inside encrypted.zip without having to give the password again.
Irrespective of this setting, you will be able to replace any file inside the encrypted archive encrypted.zip by overwriting it with a file having the same name without even knowing the old password.
But what happens in this case is that you actually delete the old file from the archive and add a new file to the ZIP file.
As you can specify a different password for each file inside an encrypted archive, you can give a new password when replacing the original file.
But you will not be able to read the file content of any file inside encrypted.zip without knowing the right password.
So, yes, you can destroy existing content, but you cannot access existing content without having the appropriate password.
--
As the ZIP file format does not permit encrypting the table of content, everybody will be able to read the TOC.
If you want to encrypt the TOC, too, then you might change to .7Z archives instead.
--
I have overwritten one of the files in encrypted.zip and given a new password "random". This password is only valid for the replaced file.
In order to access any of the other unchanged files inside encrypted.zip I had still to specify the old password. The password "random" would not be accepted for them.
I have got no real idea why T.C. should have re-zipped and re-encrypted all files inside the archive using the new password, as only 1 file has been replaced using a new password.
You must have told T.C. to replace all files in encrypted.zip, not just the changed file.
Regards,
Karl
You have created an encrypted ZIP file named encrypted.zip.
Password for all files inside the ZIP file is ASD, as you explained.
If you had enabled the [x] Remember (until program is closed or minimized) option, when confirming the password ASD, then T.C. will remember and use the password ASD as long as
+ you do not close T.C.
+ you do not minimize T.C.
This means you will be able to access the content of any file inside encrypted.zip without having to give the password again.
Irrespective of this setting, you will be able to replace any file inside the encrypted archive encrypted.zip by overwriting it with a file having the same name without even knowing the old password.
But what happens in this case is that you actually delete the old file from the archive and add a new file to the ZIP file.
As you can specify a different password for each file inside an encrypted archive, you can give a new password when replacing the original file.
But you will not be able to read the file content of any file inside encrypted.zip without knowing the right password.
So, yes, you can destroy existing content, but you cannot access existing content without having the appropriate password.
--
As the ZIP file format does not permit encrypting the table of content, everybody will be able to read the TOC.
If you want to encrypt the TOC, too, then you might change to .7Z archives instead.
--
I have overwritten one of the files in encrypted.zip and given a new password "random". This password is only valid for the replaced file.
In order to access any of the other unchanged files inside encrypted.zip I had still to specify the old password. The password "random" would not be accepted for them.
I have got no real idea why T.C. should have re-zipped and re-encrypted all files inside the archive using the new password, as only 1 file has been replaced using a new password.
You must have told T.C. to replace all files in encrypted.zip, not just the changed file.
Regards,
Karl
MX Linux 21.3 64-bit xfce, Total Commander 11.50 64-bit
The people of Alderaan keep on bravely fighting back the clone warriors sent out by the unscrupulous Sith Lord Palpatine.
The Prophet's Song
The people of Alderaan keep on bravely fighting back the clone warriors sent out by the unscrupulous Sith Lord Palpatine.
The Prophet's Song
Hello Karl,
Tnx a lot for your time! I think I get it now. Two things:
- Your last remark:
- Tnx again: 7Z suits much better, since the TOC stays invisible, prohibiting all my problems with zip.
I do have questions with the 7z plugin: I cannot find nor edit its settings. What algoritm is used AES 128, AES256, etc.?
Is the encryption level depending on compression level settings (I hope not)?
regards
Tnx a lot for your time! I think I get it now. Two things:
- Your last remark:
Correct: my files in this dir are always ALL updated, thus resetting the pw (if I choose not to enter the real pw of course)You must have told T.C. to replace all files in encrypted.zip, not just the changed file.
- Tnx again: 7Z suits much better, since the TOC stays invisible, prohibiting all my problems with zip.
I do have questions with the 7z plugin: I cannot find nor edit its settings. What algoritm is used AES 128, AES256, etc.?
Is the encryption level depending on compression level settings (I hope not)?
regards
(Actually some do. Encrypting the central directory was a feature of PKZIP and is part of the official zip specification, but more popular implementations like WinZip and Infozip don't support it, which is a shame)MVV wrote:jazzz,
ZIP archives do not support encrypting archive listing, [..]
#5050 :: Everyone who believes in telekinesis, raise my hand!
I noticed, but I do not see any encryption settings at all, only compression settings..
ps. I use 7z Plugin 0.7.6.6 by dllee
screenshot here: http://totalcmd.net/plugring/7zip_plugin.html
ps. I use 7z Plugin 0.7.6.6 by dllee
screenshot here: http://totalcmd.net/plugring/7zip_plugin.html
Hi, jazzz.
But the webpage which you link to displays a screenshot where the password settings can be spotted in he right-hand half of the configuration dialogue.
I admit that the dialogue does not offer to select from a list of different encryption algorithms. So I will have to check on the 7zip homepage which algorithm(s) it supports.
Regards,
Karl
But the webpage which you link to displays a screenshot where the password settings can be spotted in he right-hand half of the configuration dialogue.
I admit that the dialogue does not offer to select from a list of different encryption algorithms. So I will have to check on the 7zip homepage which algorithm(s) it supports.
Regards,
Karl
MX Linux 21.3 64-bit xfce, Total Commander 11.50 64-bit
The people of Alderaan keep on bravely fighting back the clone warriors sent out by the unscrupulous Sith Lord Palpatine.
The Prophet's Song
The people of Alderaan keep on bravely fighting back the clone warriors sent out by the unscrupulous Sith Lord Palpatine.
The Prophet's Song
Using Total7zip plugin it is possible to select any option that is offered by original 7-Zip, including AES key size (which is always 256 bit in 7-Zip 9.20).