431–440 of 547 posts
Earlier quoted context omitted.
Prefix the whole command with a space to avoid dumping your password into your bash history: " grep `echo -n yourpassword | shasum | cut -c6-40` SHA1.txt"
I couldn't really find a good reason to use a .bash_history. I linked mine to /dev/null and never looked back. (heh)
Some observations on this file: 0. This is a file of SHA1 hashes of short strings (i.e. passwords). 1. There are 3,521,180 hashes that begin with 00000. I believe that these represent hashes that the hackers have already broken and they have marked them with 00000 to indicate that fact. Evidence for this is that the SHA1 hash of 'password' does not appear in the list, but the same hash with the first five characters…
Good posted, upvoted. One clarification: > That's 25 users per hash Password choices are probably Zipf-distributed, so averages don't make a ton of sense.
The arithmetic mean is specifically the value you'd want. n users times m users/password == total passwords (unduplicated) in the LinkedIn database.
Zipf distribution would suggest that the pattern of reuse among passwords isn't normal, and that the median and mode are probably higher than the arithmetic mean.
Earlier quoted context omitted.
They are already unique and sorted. sort -u combo_not.txt | wc -l 6458020 wc -l combo_not.txt 6458020
I assume the first line you meant to pipe it through uniq afer the sort? Otherwise the only thing you've demonstrated is that sorting a file doesn't change its line count. :)
Earlier quoted context omitted.
They are already unique and sorted. sort -u combo_not.txt | wc -l 6458020 wc -l combo_not.txt 6458020
I assume the first line you meant to pipe it through uniq afer the sort? Otherwise the only thing you've demonstrated is that sorting a file doesn't change its line count. :)
Earlier quoted context omitted.
We're speaking about a very specific attack here: bruteforce. And I'm speaking about a very specific type of "salt" (which could probably be called something else, since it's not the same as normal unique-per-password salt): large, database-wide string of random bytes. If every password is padded with such a string before hashing, computing the hash would be slower. Obviously, it would be slower because you would hav…
How much slower would you estimate it being?
That's not that interesting by itself, but it is interesting to think about how this would affect computing the hashes on GPUs.
Earlier quoted context omitted.
Obligatory perl one-liner: perl -MDigest::SHA -le '$h = substr( Digest::SHA::sha1_hex($ARGV[0]) , 5 ); open F, " )' password (for people without shells)
Obligatory shell one-liner: grep `echo -n password | shasum | cut -c6-40` hacked.txt
printf yourpassword|sha1sum |cut -c6-40 |grep -f - SHA1.txt
Earlier quoted context omitted.
Prefix the whole command with a space to avoid dumping your password into your bash history: " grep `echo -n yourpassword | shasum | cut -c6-40` SHA1.txt"
Alternative and more dramatic method of preventing it being written to your bash history: kill -9 $$
Earlier quoted context omitted.
None of this makes much sense to me, sorry. Brute-force password cracking has worked on salted passwords since Alec Muffett released Crack in the early '90s. The amount of extra computational power required to hash a password and a salt is negligible. The only thing "salts" do is prevent rainbow table precomputation, but it's just a quirk of the late '90s and early '00s that "rainbow tables" ever became a mainstream…
Computing a hash on 1MB of data is slower than computing a hash of 6-8 bytes of data. Brute-force attacks are based on trying different passwords and seeing that after being salted they generate the same hash as in the database. Therefore, adding a large string to the password before hashing would force the attacker to hash that string. The question is, can this be pre-computed once or efficiently parallelized?
Just use bcrypt, scrypt, or PBKDF2. People have already figured this problem out.
Earlier quoted context omitted.
fwiw, this could also be an elaborate hoax, given this facts. E.g. a list of simple password + combinations of the above simple password+"linkedin" variations.
My complex unique password is also on this list (full hash no 5 0's). So nope, not a hoax. Unbelievable/insulting they didn't even bother to salt.
Earlier quoted context omitted.
Prefix the whole command with a space to avoid dumping your password into your bash history: " grep `echo -n yourpassword | shasum | cut -c6-40` SHA1.txt"
I couldn't really find a good reason to use a .bash_history. I linked mine to /dev/null and never looked back. (heh)