5 ms·

I received this e-mail and had my password reset by Github. Based on the "security history" shown in my Github account's setting page, my account wasn't compro

I received this e-mail and had my password reset by Github. Based on the "security history" shown in my Github account's setting page, my account wasn't compromised as there was no login activity during the past week. I'm thinking that this is fallout from the LinkedIn breach, because this is the first high-profile breach which includes one of my e-mail addresses. (How do I know this? I'm using haveibeenpwned.com -- a free service that I highly suggest registering with.)

jqueryin 10y ago
Just a thought, but GitHub could be handling this proactively to ensure the security of their members given the sensitivity of private repositories: Step 1: Grab LinkedIn breach data Step 2: Compare email addresses/usernames from LinkedIn to GitHub Step 3: Check if passwords are the same Step 4: Reset password and notify if they match
- zaroth 10y ago
  Step 3 is not possible without one of the following; GitHub keeps a copy of the password in plain-text GitHub keeps a copy of the SHA1 hash of the password GitHub cracks the SHA1 hash and checks against their hash GitHub calculates the SHA1 hash of the password after a valid login The 4th option is the only sane approach, but it means you can't 'Check if passwords are the same' in bulk, only as users login.
  - Someone1234 10y ago
    The LinkedIn dump is trivial to convert back into plain text. They're all SHA1 hashes and aren't salted. You can just download an SHA1 rainbow table[0] and instantly convert them to plain text. [0] http://project-rainbowcrack.com/table.htm http://project-rainbowcrack.com/table.htm
    - jeffjose 10y ago
      Correct me if I'm wrong, but rainbow table is for popular password and character combinations yes? If my password is s0m3th1nggsup33rhard, you cant make out the string from the rainbow table.
      - chrisrhoden 10y ago
        You're wrong. It's not just a dictionary. While tables are generated with a cap on length and characters used that's not the same as being for popular passwords.
      - Someone1234 10y ago
        Depends on the specific rainbow table. The ones I linked to are brute force, every single SHA1 hash for all common ascii characters up to 8 digits long. You can also download smaller rainbow tables for common passwords, dictionaries, or similar. Ultimately SHA1 is extremely fast to commute in 2016. So even if a rainbow table doesn't suit your needs, you can easily generate a new one which does, but likely you'll break a good chunk of passwords just using the "out of the box" 1-9 A-Za-z0-9 and specials rainbow tables.
tptacek 10y ago
That's good and all, but, really: get a password manager and start using it. Nobody can afford to share passwords between services anymore.
- eterm 10y ago
  Any password managers you would recommend? Anyone looking right now is stuck with the paradox of choice[1], it's easy to look at the list and say for any given manager, "yeah but <x> says that one is rubbish" and end up picking none and just using ~/password.txt. [1] http://uk.pcmag.com/password-managers-products/4296/guide/the-best-password-managers-for-2016 http://uk.pcmag.com/password-managers-products/4296/guide/th...
  - majewsky 10y ago
    Then at least 'gpg --encrypt ~/password.txt'.
  - tptacek 10y ago
    The only one I recommend is 1Password, but most of them are better than nothing.
    - cpach 10y ago
      1Password rocks! Really smooth UI.
  - Gaelan 10y ago
    I'm a fan of SuperGenPass[0], though you need to use the "mobile" version. The bookmarklet is insecure. [0]: https://chriszarate.github.io/supergenpass/ https://chriszarate.github.io/supergenpass/
  - tgsovlerkhgsel 10y ago
    Your browser most likely already has one that is well inegrated. Doesn't solve the problem of sites that try to prevent it from working or non-web things, but covers most cases.
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.

jqueryin 10y ago

Just a thought, but GitHub could be handling this proactively to ensure the security of their members given the sensitivity of private repositories: Step 1: Grab LinkedIn breach data Step 2: Compare email addresses/usernames from LinkedIn to GitHub Step 3: Check if passwords are the same Step 4: Reset password and notify if they match

zaroth 10y ago
Step 3 is not possible without one of the following; GitHub keeps a copy of the password in plain-text GitHub keeps a copy of the SHA1 hash of the password GitHub cracks the SHA1 hash and checks against their hash GitHub calculates the SHA1 hash of the password after a valid login The 4th option is the only sane approach, but it means you can't 'Check if passwords are the same' in bulk, only as users login.
- Someone1234 10y ago
  The LinkedIn dump is trivial to convert back into plain text. They're all SHA1 hashes and aren't salted. You can just download an SHA1 rainbow table[0] and instantly convert them to plain text. [0] http://project-rainbowcrack.com/table.htm http://project-rainbowcrack.com/table.htm
  - jeffjose 10y ago
    Correct me if I'm wrong, but rainbow table is for popular password and character combinations yes? If my password is s0m3th1nggsup33rhard, you cant make out the string from the rainbow table.
    - chrisrhoden 10y ago
      You're wrong. It's not just a dictionary. While tables are generated with a cap on length and characters used that's not the same as being for popular passwords.
    - Someone1234 10y ago
      Depends on the specific rainbow table. The ones I linked to are brute force, every single SHA1 hash for all common ascii characters up to 8 digits long. You can also download smaller rainbow tables for common passwords, dictionaries, or similar. Ultimately SHA1 is extremely fast to commute in 2016. So even if a rainbow table doesn't suit your needs, you can easily generate a new one which does, but likely you'll break a good chunk of passwords just using the "out of the box" 1-9 A-Za-z0-9 and specials rainbow tables.

tptacek 10y ago

That's good and all, but, really: get a password manager and start using it. Nobody can afford to share passwords between services anymore.

eterm 10y ago
Any password managers you would recommend? Anyone looking right now is stuck with the paradox of choice[1], it's easy to look at the list and say for any given manager, "yeah but <x> says that one is rubbish" and end up picking none and just using ~/password.txt. [1] http://uk.pcmag.com/password-managers-products/4296/guide/the-best-password-managers-for-2016 http://uk.pcmag.com/password-managers-products/4296/guide/th...
- majewsky 10y ago
  Then at least 'gpg --encrypt ~/password.txt'.
- tptacek 10y ago
  The only one I recommend is 1Password, but most of them are better than nothing.
  - cpach 10y ago
    1Password rocks! Really smooth UI.
- Gaelan 10y ago
  I'm a fan of SuperGenPass[0], though you need to use the "mobile" version. The bookmarklet is insecure. [0]: https://chriszarate.github.io/supergenpass/ https://chriszarate.github.io/supergenpass/
- tgsovlerkhgsel 10y ago
  Your browser most likely already has one that is well inegrated. Doesn't solve the problem of sites that try to prevent it from working or non-web things, but covers most cases.

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.