4 ms·

I knew I had already been "pwned" from adobe, but I just checked again and I was done in again from x-split. I've since switched to using secure (60bit) passwo

by eterm 10y ago

I knew I had already been "pwned" from adobe, but I just checked again and I was done in again from x-split. I've since switched to using secure (60bit) passwords everywhere, but these are just the ones that have been made public, for every public release of info there are likely cases where the data has been kept privately. Passwords suck, I wish everywhere had support for 2fa. Here's a "did you know" about passwords: Did you know blizzard only uses the lower-case for passwords? You can enter any case of password and still match, so for blizzard always use a longer password because 'a' and 'A' are not unique.

knd775 10y ago
Oh wow, that's awful. How can companies think that this is okay?
- chias 10y ago
  See also: Chase Bank
Natanael_L 10y ago
I suggest 80+ bits to avoid getting caught by rainbow tables and similar batch attacks, which can get you in cases of password database dumps. 64 bit keys have already been cracked many times over in various distributed efforts. If some site just uses plain MD5 then raw bruteforce might have already come across your password, or might do so anytime in the future.
- eterm 10y ago
  The 60 bits refers to my passwords generated rather than password storage, where I would use something much stronger. (bcrypt or better!) So for instance length 10 passwords each character from a list of 64 characters (the usual [a-zA-Z0-9] plus some special characters, minus confusable ones) is generated with 60 bits. Increasing that to 12 characters gets to 72 bit, beyond that is hard to manage. Rainbow tables is about getting into an account from hashes, and doesn't typically actually resolve the actual password used, but something that instead hashes to the same thing. (In a rainbow attack you would hash H(X) then H(H(X)) then H(H(H(X))) etc, eventually for every hash you have something that hashes to that hash. Obviously this only works for small hash lengths and are what salts were designed to protect against. But you're not hashing actual passwords, you're hashing the random results. When you're hashing passwords, those are dictionary attacks. If there's no salt or a weak (single-site-salt) salt then you can pre-hash a whole dictionary. Otherwise you have to hash a dictionary for each salt. But 60 random bits are unlikely to appear in any dictionary attack. I'm not saying 60 bits of entropy in a password is enough to protect against a targeted attack, but it's enough to stop the password being found through a dictionary or cheap attack, which is all you can really protect for (you shouldn't re-use passwords anyway), the rest is up to the site operator to secure your password with hashing, at which point the salt has more entropy than your password anyway. For a master password I'd obviously recommend going a lot stronger. Ultimately, if a database has been completely owned, then you can't really protect against someone getting into that account, they could just do an "UPDATE users SET password=null" after all. So eliminate all password re-use, prevent your passwords being dictionary guessable, and secure your password list with a very strong master password.
v0x 10y ago
Regarding Blizzard passwords: an old acquaintance generated his own SHA-1 hashes for his Battle.net account - which did not resolve to characters which could be input by a regular client - so nobody else would be able to login to his account even if they had the information. Pretty neat.
- tamana 10y ago
  How did he log in?

by eterm 10y ago

knd775 10y ago

Oh wow, that's awful. How can companies think that this is okay?

chias 10y ago
See also: Chase Bank

Natanael_L 10y ago

I suggest 80+ bits to avoid getting caught by rainbow tables and similar batch attacks, which can get you in cases of password database dumps. 64 bit keys have already been cracked many times over in various distributed efforts. If some site just uses plain MD5 then raw bruteforce might have already come across your password, or might do so anytime in the future.

eterm 10y ago
The 60 bits refers to my passwords generated rather than password storage, where I would use something much stronger. (bcrypt or better!) So for instance length 10 passwords each character from a list of 64 characters (the usual [a-zA-Z0-9] plus some special characters, minus confusable ones) is generated with 60 bits. Increasing that to 12 characters gets to 72 bit, beyond that is hard to manage. Rainbow tables is about getting into an account from hashes, and doesn't typically actually resolve the actual password used, but something that instead hashes to the same thing. (In a rainbow attack you would hash H(X) then H(H(X)) then H(H(H(X))) etc, eventually for every hash you have something that hashes to that hash. Obviously this only works for small hash lengths and are what salts were designed to protect against. But you're not hashing actual passwords, you're hashing the random results. When you're hashing passwords, those are dictionary attacks. If there's no salt or a weak (single-site-salt) salt then you can pre-hash a whole dictionary. Otherwise you have to hash a dictionary for each salt. But 60 random bits are unlikely to appear in any dictionary attack. I'm not saying 60 bits of entropy in a password is enough to protect against a targeted attack, but it's enough to stop the password being found through a dictionary or cheap attack, which is all you can really protect for (you shouldn't re-use passwords anyway), the rest is up to the site operator to secure your password with hashing, at which point the salt has more entropy than your password anyway. For a master password I'd obviously recommend going a lot stronger. Ultimately, if a database has been completely owned, then you can't really protect against someone getting into that account, they could just do an "UPDATE users SET password=null" after all. So eliminate all password re-use, prevent your passwords being dictionary guessable, and secure your password list with a very strong master password.

v0x 10y ago

Regarding Blizzard passwords: an old acquaintance generated his own SHA-1 hashes for his Battle.net account - which did not resolve to characters which could be input by a regular client - so nobody else would be able to login to his account even if they had the information. Pretty neat.

tamana 10y ago
How did he log in?