101–110 of 547 posts
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.
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…
Interesting - I wasn't able to find the hashes of any passwords in the list. What list were you using?
Edit: I'm not sure I understand what you mean - there was 100k passwords in one file, already cracked, and another with all 6.5M hashes. I found my hash in the hashes file.
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?
Because the passwords aren't salted(stupid), you might get multiple hits for the same hash(for example, for the good old "1234" password), meaning you might end up contacting more users than actually affected. Better safe than sorry.
Earlier quoted context omitted.
Me. Admittedly, it's stupid as hell, but has generally been too much of a pain to do anything else (for things outside of banking, email). I've started to get serious about KeePass lately, but I bet a significant percentage of users take the lazy approach.
Having to type in my Apple password on iOS once every few hours inevitably means I have to use something memorizable and quick to type. There are certain trade-offs with different passwords.
If you're doing something that makes that normal procedure, consider using the browser inside 1Password for iOS.
I've just downloaded the database linked and it only contains the hashed passwords, not the account usernames / e-mail addresses. I wonder if someone has the account details to match up otherwise you've no idea which password belongs to who, and you'd hope that LinkedIn would have lockout functionality.
Agreed. That seems rather useless. How would that happen anyway? The usernames stored in a different database/table from the hashes?
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.
Earlier quoted context omitted.
No they're not. I tried the following: > irb > require 'digest/sha1' > Digest::SHA1.hexdigest 'my_password' => hash_string Then I searched the file with the hash string and found my password. I really hope they don't also have the usernames somewhere.
Interesting, I tried this with a bunch of different passwords (though using php's sha1 function, which obviously gives the same output as ruby's), and found no matches. You're using the "combo_not.txt" file from the zip file in the ggp, right?
Considering how usernames weren't leaked, there's a big chance that the intruder is just sitting on them and the other passwords.
There should be a huge banner on linked in urging users to change their passwords in my opinion.
Then I get to choose what strength lock I put on it.