GitHub Security Update: Reused Password Attack
github.com
github.com
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.)
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 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 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.
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/th...
*of course I need multiple browsers; even in 2016, the Browser Wars are not over.
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.
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.
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.
Obviously one where an attempt was made, and succeeded, would count as affected.
But would an account where an attempt was made, and failed, also count?
What if the userid and password are correct, but 2FA stopped the attack on an account. Is that account affected, in their view?
I wouldn't think so. There must be countless incorrect password attempts all the time.
> What if the userid and password are correct, but 2FA stopped the attack on an account. Is that account affected, in their view?
Interesting question. I'd hope they'd inform me if somebody had my password and was only blocked by 2FA.
For either method, you can audit the activity of your account on the GitHub security page: https://github.com/settings/security. For example, upon having deliberately got my 2FA token wrong, "user.two_factor_requested" and "user.failed_login" events were logged for me.
I'm gonna change my password just in case.
Here's an idea I just thought of: sites should have a standardized, secondary place to log in, where if the login is correct it automatically disables the password and requires a reset. "Report a compromised account", as it were. Anyone (or maybe specific whitehat groups) should have explicit permission to try any logins they want there: after all, if they succeed in logging in then the right thing happens and the account is locked. It's impossible to gain any illicit advantage from such access because any correct credentials are locked as soon as you try them. (Is this assumption robust?) So whitehats could then take lists and throw them against sites that implement this standard, but no attackers can gain from this.
The only problem I see is that disabling rate limits would open you to DOS (also if multiple people use the same list, although better coordination would help solve that): maybe allow bulk uploads which take less bandwidth overall.
Does this idea have any value?
"Hello,
At Amazon we take your security and privacy very seriously. As part of our routine monitoring, we discovered a list of email addresses and passwords posted online. While the list was not Amazon-related, we know that many customers reuse their passwords on multiple websites. Since we believe your email addresses and passwords were on the list, we have assigned a temporary password to your Amazon.com account out of an abundance of caution."
With my idea the people with the data would be able to directly shut down the accounts ethically.
Maybe the proposal could also hash and salt the passwords before sending it to the site, which sounds even better for security and wouldn't be too much of a hassle for whitehats who want to help.
I don't quite get your concern. Isn't that better than them getting their account hacked?
One big advantage of U2P is protection against phishing and mitm attacks, which OTP is vulnerable to. There is more information here: https://developers.yubico.com/U2F/Protocol_details/Overview....
(I'm not affiliated with the site, I just check it periodically and thought it might be of use here.)
Bitbucket provides an audit log and a list of recent login sessions where you can see if your account has been accessed and if anything destructive was done to it. Github has a similar feature I think.
I just started using it a few weeks ago. Supposedly it uses a password to encrypt the data, but I still don't feel too confident syncing them there. On the other hand.. damn it's so convenient between multiple devices.
Your browser is not a competent password manager and you should stop using it for that immediately.
Dashlane and LastPass make their money by keeping your passwords safe. This is far more preferable than a free browser feature. Both can sync across devices (if you pay). Sounds like you will like Dashlane for the same reasons that I do.
It does, but it gives you a VERY strongly-worded warning when you enable that.
I like LastPass for a few reasons -
* It lets me share my personal account with my work account so I can keep them separate (so when I log in on my work PC, I still have my personal passwords, but I log in to my personal account on my devices so I don't have to worry about someone getting access to work passwords on there).
* 2FA
* If I try to set a master password that's the same as one of my passwords I'm storing in there, it warns me.
* Cross-platform
But that just won't happen. So many sites can not even accept big passwords, they won't all migrating to any sane schema.
I agree with your assessment of what biometrics can and cannot do. That is why I specifically said that in most situations, passwords are only used to verify someone's identity, and thus can be replaced with biometrics.
It's not a completely ideal password manager, but it works.
If you can remember your password, then you shouldn't be typing it into a remote system, period.
Additionally, how do you determine the service name? e.g. I have a wordpress.com account; do I call that 'WordPress' or 'wordpress' or 'wordpress.com'? I guess using the domain name is fairly robust, but then you get stuff like Stack Exchange, or the service changes its domain name, or international variants - google.com vs. google.co.uk.
As for the service name I've had no issues with that in my use. Just come up with whatever rule is easy for you to remember. Worst case you'll have to make a few tries.
now a site has been breached and your username/password was leaked... yay, you'll have to either start using a traditional password manager for this special case or change every.single.password.you.have.
so useful ...not!
[1]: https://en.wikipedia.org/wiki/Length_extension_attack
[2]: https://crypto.stackexchange.com/questions/18606/is-xoring-a...
Power of the network effect that I won't leave Linkedin, and wouldn't think twice before spending money on the platform if I needed to recruit someone or do b2b sales. But screw Linkedin for not taking proper precautions.
The real problem is the way that we do passwords. Passwords should either be managed by your browser or your operating system. When you log in to your computer, you log in one time with a public key. And then your OS/Browser automatically logs you into every website you visit by signing challenges instead of by giving your private key (that's essentially what a password boils down to) to everyone who wants to verify your identity.
The same is true for credit cards.
If we want a more secure web, we will replace the password system. It's difficult to use passwords correctly, even if you have the common sense (which a lot of people don't, because they just don't realize it's a bad idea).
It should be a higher priority. People are clearly losing money and losing quality of life over today's insecure password infrastructure.
Right now there are many solutions for password management. Free and open source, free and closed source, paid and closed source, enterprise. You name it! "Good password hygiene" is fairly ubiquitous amongst people on this site.
With that said, credential management[0] is coming. Google and Apple want to kill LastPass, 1password, and all these companies, and they definitely will AFAICT.
Odd way of phrasing it. It's more accurate to say "you're pointing out that they have put themselves at risk through a number of insecure practises". It's not so much blaming a girl for getting raped; more "don't walk around an area that suffers from high crime, at night, using an expensive phone and getting a laptop and flashy camera and act surprised if you get robbed".
I, too, may even have used that pw on twitter (RIP both followers of my 4 tweet history). Again, because I don't really care.
I have essentially been re-using passwords for 15 years now (although my very first password on my AOL "gandalf" has long been retired), every now and again upgrading my "default strong" and using a the historical weaker ones on things I don't care about/don't trust.
Password Manager is definitely a smarter solution but I can't see myself setting it up.
A mix of laziness, apathy and habit lead me to reuse that password on many sites. But I have 5+ email addresses, tons of shopping accounts, multiple banks, brokers, airlines, hotels, etc. I do use more secure passwords for other sites.
I really can't be bothered into using a password manager, so what's the alternative besides reusing passwords?
The alternative is getting burned by password reuse repeatedly until you can be bothered, I would assume. Alternatively, you could cling to the hope that a more secure and more convenient authentication mechanism gets adopted somewhere in the next decade or two.
I'm not sure calling LinkedIn the shooter in this analogy is completely fair; maybe more like the cop two streets over getting a donut.
To compare your new password with your old password, you take the old salt, hash your new password together with it, and compare the result to the old hash. If they match, you're trying to reuse the same password. You do this on the server side, naturally.
If salted hashing were done on the client side, it means you're actually sending username + saltedhash, instead of username + password to the server to log in.
So an attacker could submit a precomputed or stolen salted hash to be compared against the stored one -- completely defeating the point of hashing passwords in the first place.
So that the server never gets any plaintext.
>So an attacker could submit a precomputed or stolen salted hash to be compared against the stored one -- completely defeating the point of hashing passwords in the first place.
You could hash once on the client and once on the server to get the best (?) of both worlds. Really only the server one needs to be salted.
Mitigates attacks that exploit the server but not the served js.
See also https://security.stackexchange.com/questions/53594/why-is-cl... for some discussion: the first answer has the same thing I proposed, hashing on both the client and server.
I guess another benefit might be constant size passwords, which may mitigate side channels or sniffing.
How can it hurt? If there's no harm, but some upside, then why not?
As for the disadvantages, it makes logins take longer, forces the use of JavaScript, increases the complexity of code and increases the site size.
You can as long as it stays the same over time. Either lookup salt by username (requires an extra call back and forth) or use a single salt for the whole site, or actually you could have the salt deterministically depend on the username. All of those defeat hash tables.
I agree that the password length problem is not a great benefit, but the benefit that the server never sees the plaintext is pretty good in my eyes.
Logins take longer: a single hash+salt won't make a big difference even on low end devices.
Javascript: fair point, although plenty of sites require it for signing in anyway. I suppose you could make it optional.
Complexity of code: if it's in a library and vetted this doesn't matter as much. Conceptually this is pretty simple, would probably be 3-5 lines of code (2 lines to hash, 2 lines to generate salt from username).
And here you just answered your initial point.
> If the salt changes, you'd need to compute the password using multiple salts, which might have crypto guarantee issues when sent to the server.
After that you can ditch server-side hashing, and use authentication protocol like CRAM-MD5 (I don't remember what the modern alternatives are) to protect against network traffic interception. While still not technically storing your users' passwords in the database.
EDIT: Using asymmetric crypto with a private key derived from the password would probably be better. But still, client-side hashing DOES gain you something.
We'd all be dealing with password resets on a daily basis.
As he said, those counts are obviously affected, but the article (and your quote) give no indication of if accounts in the other categories (attempted but failed, attempted but stopped by TFA) are also notified that attempts were made.
Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
In this case a comment rather than an article, but the rule still applies. Consider how much more polite your comment would be with just the second paragraph.