231–240 of 547 posts
Earlier quoted context omitted.
[deleted]
Possible that they only uploaded the "hard" ones. Looks from other comments here that people have found their own passwords, unsalted.
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…
E.g. a list of simple password + combinations of the above simple password+"linkedin" variations.
Earlier quoted context omitted.
I've always wondered this about services like lastpass. What stops being hacked / keyloggered and them exfiltrating all your long, complex passwords?
Nothing, really. However, I trust the LastPass guys to keep their shit secure as much as I trust myself to keep my own system secure. After all, if my own system is compromised, I just get a lot of hassle. If LastPass ever gets hacked and leaks their passwords, they lose their business overnight. That's pretty good motivation for them to keep on top of their stuff. I used to use 1Passwd, which stored the passwords in…
No. This is the strength of two-factor authentication, something you know, and something you have. If someone gets your 1Password keyfile, it's useless without your decrypting password.
Earlier quoted context omitted.
Surely just hashing the username|password would massively reduce the effectiveness of leaks like this? Sure, a hacker would know what the "salt" is, but since it now varies between users you would expend the same amount of effort breaking one person's login as you previously would spend breaking everyones (on average). (Not recommending it, just wondering if my reasoning is correct.)
I hear this commonly, so it is a good idea to clear it up. Usernames have lower entropy than a random salt and are predictable in many cases. People re-use usernames and some usernames are common. If your password system became common on the web, or if I knew the workings of your password system (i.e. open source / leaked codebase / Kerckhoffs's principle[1]), I could generate a rainbow table for either common or tar…
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…
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.
Earlier quoted context omitted.
Surely just hashing the username|password would massively reduce the effectiveness of leaks like this? Sure, a hacker would know what the "salt" is, but since it now varies between users you would expend the same amount of effort breaking one person's login as you previously would spend breaking everyones (on average). (Not recommending it, just wondering if my reasoning is correct.)
I hear this commonly, so it is a good idea to clear it up. Usernames have lower entropy than a random salt and are predictable in many cases. People re-use usernames and some usernames are common. If your password system became common on the web, or if I knew the workings of your password system (i.e. open source / leaked codebase / Kerckhoffs's principle[1]), I could generate a rainbow table for either common or tar…
For a targeted attack it really doesn't matter as the time complexity to produce the rainbow table is equivalent to that of simply brute forcing the hash, ie, you can't say 'well assume the rainbow table contains only some small number of usernames"...
It also is entirely unlike the WPA2 rainbow tables in that you don't have millions of users all sharing the same username (ie. factory default SSIDs).
Overall it's more secure then it seems at first glance but you still have to ask yourself why you'd use that over a random salt.
"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…
What do you recommend users do instead? Unfortunately there will probably always be websites storing passwords in unsecure ways. I mean I'd certainly rather not have to deal with the hassle (however small) of using LastPass, but as you said, that's the world we live in. Hoping for competence by the writers/maintainers of websites is also flawed computer security, is it not?
The reason I'm annoyed with this particularly is that larger sites are more likely targets due simply to their size. Larger sites generally have the developer resources to provide a good solution to the problem from their end but commonly don't.
This makes them look bad and means their users are left in more danger than before. No-one wins.
Earlier quoted context omitted.
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…
The difference is that if it's salted you need to work to get a specific password. Without salting you can test a generated hash (rainbow table) against all 6.9 million hashes at the same time. Not defending the choice - bcrypt is obviously a much better way to go.