61–70 of 547 posts
Earlier quoted context omitted.
You can use it for checking whether your password was leaked. You don't need usernames for that.
Are the hashed passwords not salted?
Earlier quoted context omitted.
... but still, a head wag at LinkedIn for using weak hashing, which I'm guessing means MD5.
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 is a major reason to use bcrypt.
This makes me wonder. I've been relying on Django's built in user authentication lately. Does anyone know if that's pretty safe? Is it doing the right thing for hashing passwords?
Disclaimer: I am not a cryptographic expert. https://docs.djangoproject.com/en/dev/topics/auth/ Django by default uses the PBKDF2 algorithm, which is better than nothing/md5/no salt sha1. I'd use bcrypt or scrypt by default, better be 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.
I've developed a system (kept only in my head) where every password I use is based off on the name of the service. This means that with just one of my passwords, you're most likely not getting anywhere. With two, you have a bigger chance of figuring out the differences and thus the system, but it works fine for me at the moment.
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.
I've developed a system (kept only in my head) where every password I use is based off on the name of the service. This means that with just one of my passwords, you're most likely not getting anywhere. With two, you have a bigger chance of figuring out the differences and thus the system, but it works fine for me at the moment.
Usually something like "domainname"+"common password for all sites"
Earlier quoted context omitted.
... but still, a head wag at LinkedIn for using weak hashing, which I'm guessing means MD5.
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.
What riddles me though, is how come 6.5 million? LinkedIn has what, 150M users? Did they not post the entire load (and are in fact sitting on _all_ the hashes?) Is the dump an old backup or breach from when they had fewer accounts? Is it just one DB partition / file that's been lost, an archive?
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.
just use a couple of shitty passwords for sites you don't care about, and remember the other ones. E.g. my hacker news account would probably be relatively unproblematic to compromise. If that were to happen, I'd just make a new one though.
I don't like the idea of identity permanence.
Instead of shitty passwords though, why not use something like 1Password to store the logins? I use that (or an old fashioned piece of paper in a secure location) for meaningful security tokens.
Earlier quoted context omitted.
Are the hashed passwords not salted?
You can perform this check even if they were salted. Otherwise how could linkedin check if you correctly entered your password? The salt is contained in cleartext as part of the hashed password, so that you can repeat the hashing the secret and match the two hashes. The salt improves the security because: 1. even if two users use the same password, you cannot tell that by simply comparing the hashes 2. makes brute fo…