121–130 of 547 posts
Good Guy Startup Founder would cross reference this password list with their own password system and force those that match to reauthenticate and change their passwords. This wouldn't be difficult to do and your users would appreciate it.
How would one cross-reference this list unless you're storing the plain text passwords?
Earlier quoted context omitted.
THANK YOU "use bcrypt" has become an HN meme, with all the bad implications of it As if scrypt, pbkdf2 didn't exist. Or as if bcrypt has always existed and doesn't have any weakness
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.)
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
Good Guy Startup Founder would cross reference this password list with their own password system and force those that match to reauthenticate and change their passwords. This wouldn't be difficult to do and your users would appreciate it.
Earlier quoted context omitted.
MD5 isn't the issue - it's the lack of salting. Without a salt, almost any hash can be cracked with a rainbow table. With a salt, you'd need to know the salt for each hash, and then generate a new rainbow table, in order to recover the original password.
This isn't really the issue. The real issue is that MD5 (though these hashes are SHA1, which has the same problem) are too easily computed; they are practically byte-forceable. I don't need a rainbow table to compute hashes when I can slam out millions in short order using a GPU. You have a good point about needing to know the salt, but getting the salt is generally easy because it's usually stored in the same place…
What prevents developers from adding a large DB-wide salt (in addition to normal salt) to every password? Wouldn't that prevent bruteforce attacks regardless of the hashing algorithm?
Earlier quoted context omitted.
Keep in mind that whoever leaked the hashes is probably keeping the usernames / emails for themselves. The forum in question doesn't allow posting of user-identifiable information according to the forum guidelines. The leaked hashes seems to be SHA-1. I've also confirmed that the hash of my own (semi-complex) LinkedIn password is in the list. Accidentally this is the same password as I had for HN and that I've now ch…
As a more general question: why is it not an industry standard to salt with the username/email in addition to the random key? (i.e. Sha1($salt + $email + $password)). Even if the random salt were excluded, I would think that this is much more secure. Existing rainbow tables would not be anywhere near as helpful, and attempts to generate a rainbow table for a specific salted database would be ineffective because the s…
I think this is a pretty good overview: http://codahale.com/how-to-safely-store-a-password/
Earlier quoted context omitted.
How would one cross-reference this list unless you're storing the plain text passwords?
The released passwords are hashed with SHA1. Assuming you use the same algorithm and linkedin does not use a salt (they probably do), then you could just compare the hashes.
Good Guy Startup Founder would cross reference this password list with their own password system and force those that match to reauthenticate and change their passwords. This wouldn't be difficult to do and your users would appreciate it.
How would one cross-reference this list unless you're storing the plain text passwords?
Am I glad that I use LastPass and have a different, 12-character password for every service? Why, yes, yes, I am. I've now changed my LinkedIn password, too, just in case.