211–220 of 547 posts
Earlier quoted context omitted.
How can you tell?
Not finding 'password', 'foobar', '1234' suggests salted passwords.
Edit: '12345678' is in there, further bolstering the length requirement theory.
Earlier quoted context omitted.
I'm not familiar with iterations, anybody care to clue me in? I would have thought salted sha-1 would be decent for password hashing, though not the most solid possible, but at least not laughable. Is that not the case?
It is not. Sha1 is designed to be fast. You want your password hash function to be slow, so that an attacker has to spend as much resources as possible to brute force it. Of course, it does not mean you should take a slow implementation of a fast hash. You need a hash that, when implemented to be as fast as possible, still is pretty slow.
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…
For the security novices amongst us: I had no idea how to do this so I figured out a quick python script to test it: >>> from hashlib import sha1 >>> def check_pass(plaintext, offset=5): hashed = sha1(plaintext).hexdigest() return (hashed, '0' * offset + hashed[offset:]) >>> check_pass("linkedin") ('7728240c80b6bfd450849405e8500d6d207783b6', '0000040c80b6bfd450849405e8500d6d207783b6') Edit: I'm pretty sure JtR refers…
perl -MDigest::SHA -le '$h = substr( Digest::SHA::sha1_hex($ARGV[0]) , 5 ); open F, ")' password
Earlier quoted context omitted.
This is why I use 1password and not LastPass - the encrypted password file is stored locally - optionally in Dropbox, which is what enables moble and remote (http online through Dropbox) to work. Works excellently!
I use KeePass right now synced with Dropbox - what keeps me up at night is the fact that if the bad guys got my password file today, there could turn out to be a vulnerability in it discovered years from now that could allow them to get my password.
The forum they are talking about apparently (found using google) http://forum.insidepro.com/viewtopic.php?p=96122&sid=133...
I just looked into the file (combo_not.txt). There are only hashes. Who decided that the hashes posted in the forum are related to linkedin in any way ? Thank you.
Earlier quoted context omitted.
If a database of bcrypted passwords from LNKD had been leaked, we'd be having a totally different conversation right now. (Same, of course, with scrypt etc.)
Like you can't break bcrypt... The weakest link, either in bcrypt or MD5 is the password quality. Of course, in pure MD5 today you're a google search away and modern computers can eat salted MD5 for breakfast But the easiest passwords are going to be broken first
So yeah, the weakest passwords will always fall, but good solutions will go to great length to protect even the most clueless of users.
"We were curious what would happen to our share price if our company did something incredibly stupid" The above comment might seem incredibly harsh, but really, there's no good excuse for a site this prominent to not have a salted, secure password hashing system. Even if they started with an unsalted password system, users can be migrated to the newer more secure system on next login. The only way I could regain resp…
Regarding requiring users to log in; wouldn't it be better to run their current hash through another password hashing scheme (while we're at it bcrypt, scrypt, PBKDF, etc)? Then, the next time they log in, verify them by running their password through the old algorithm, and the result through the new one.
"We were curious what would happen to our share price if our company did something incredibly stupid" The above comment might seem incredibly harsh, but really, there's no good excuse for a site this prominent to not have a salted, secure password hashing system. Even if they started with an unsalted password system, users can be migrated to the newer more secure system on next login. The only way I could regain resp…
Regarding requiring users to log in; wouldn't it be better to run their current hash through another password hashing scheme (while we're at it bcrypt, scrypt, PBKDF, etc)? Then, the next time they log in, verify them by running their password through the old algorithm, and the result through the new one.
Earlier quoted context omitted.
KeePass works well too - open source, offline solution that has an "Autotype" function. I actually only run into passwords that are a pain on mobile devices. Now that my Android phone has no keyboard but tons of power, that's becoming more and more significant.
You know there's a KeePass app for Android right? I sync my KeePass db between Windows, Linux, and my Android phone using DropBox. Works great.
Given they haven't confirmed they've found and closed the leak, is it wise for everyone to be changing their passwords already?
If you find your hash in the list, you should change your password. If you don't, you should change your password.
I use LastPass to manage my passwords so I just generated another random 20+ char password and forgot about it.