The information that you are seeing may be referring to known bugs that were reported in 2019 concerning weak random number generation, and a flaw in the way that the IV is generated, in versions of 7zip at that time:
It seems that these bugs have been ...
TL;DR: You are fine, generate a long password (60+ chars), send the file by mail and the password by SMS, fax, snail-mail or phone call.
Does this mean that 7ZIP encryption is basically useless?
Short answer: No.
Long answer: It depends on the password.
A password cracker just tries passwords over and over again, either by trying all words on a dictionary (...
7zip is secure since it uses AES-256 in CBC mode that can provide CPA security and there is no problem there. Keep in mind that CBC has no integrity and authentication. The real problem comes from the human side; the password!
7zip uses 219-times iterated SHA256 to derive the AES-256 key from passwords. SHA256 is not a memory-hard function and therefore this ...
Password crackers are basically programs that take a massive password list and bruteforce the zip file in hopes of getting a positive hit (right password).
Quick fix is to just set up a strong password that has a probability of not being in a password list (Recommended to use a random password generator with min. 20 characters, alphanumeric, upper and lower ...
You're using username like a salt and pepper mix with the weaknesses both both. A pepper should be secret. The usernames are, at best, obscured. Both the salt and pepper should be random. The usernames are not random. And it has the worst feature of a pepper: if the username changes the password must also change.
If they forget their password there is no way ...
A random list of concerns without actual security threat estimation:
GDPR and similar data protection regulation might be an issue in that it might require you to also delete the username entry when a user requests full deletion of their data; how do you identify both entries? are you asking for the username and the password in the deletion form? or for the ...
Before getting into the analysis of the process to slow down cracking the hashes, I want to address something far more important first:
If I log in, and my hash happens to match some other user, I will get authenticated to that user. So your whole "look in the Users database to blindly find any match because I don't tie password hashes to users" is ...
After some thinking, I will suggest that there is no significant security improvement.
Let's put the standard account protection: salting the password with a time-consuming algorithm (bcrypt, and so one). What a attacker can do :
Reverse the hash: almost impossible
Bruteforce the hash: almost impossible if the password is longer than 6 chars (because of ...
I think the problem is that you're setting the --format to raw-MD5, while the$6$ at the beginning of the hash tells you it is a hash of type SHA512 crypt .
Here is what the numbers at the beginning of the hash mean:
$1$ is MD5
$2a$ is Blowfish
$2y$ is Blowfish
$5$ is SHA-256
$6$ is SHA-512
john should be able to detect this automatically if you do not use ...
Since chrome v80, chrome encrypts cookies and passwords using AES256-GCM with a randomly generated key. The key used for encryption is then encrypted with DPAPI and stored in the 'Local State' file in the user's chrome profile. However, the DPAPI is used in Local_Machine scope which means that any user on the computer where the encryption was done can ...
The path is the URI path that accepts credentials. While "/" may work in some cases, you may have to look at the requests your browser sends during login to determine the path (e.g. maybe something like "/cgi-bin/login").
The weakest point appears to be your "stored information", which contains the possible rules for your passwords. So, for example, if the attacker knew that your password for example.com must be generated as a case insensitive 12-char string, this information will be useful to set up a more efficient bruteforce attack on example.com. The security of ...
The way I solved this is by editing an already present dynamic config in john the ripper jumbo. I opened dynamic.conf and edited dynamic_1029 to look like this:
Expression=sha256($p.$s) (hash truncated to length 32)
I'm not aware of an attack tool that will currently do this without at least some external processing (which means reduced speed):
hashcat supports the format (-m 22300), but doesn't check for truncation
JtR appears to support the format (with a dynamic mode), but doesn't check for truncation
MDXfind checks for truncation, but doesn't support the format
If you're picking uppercase and lowercase letters uniformly at random, that's log2(52) = 5.7 bits per character, so 5.7 × 8 = 45.6 bits for an 8-character password. And the answer to the worry that you have a 2-45.6 chance of randomly choosing password (one in thirty-something trillion) is that you probably shouldn't worry too much that you have about a one ...