
GitHub Security Update: Reused Password Attack - ejcx
https://github.com/blog/2190-github-security-update-reused-password-attack
======
kiwidrew
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.)

~~~
eterm
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.

~~~
Natanael_L
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
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.

------
natch
What the page doesn't tell me is: What is their definition of an "affected"
account?

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?

~~~
paulannesley
> But would an account where an attempt was made, and failed, also count?

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.

~~~
DanCardin
Wouldnt you have gotten unexpected 2fa notifications if that were the case?

~~~
nathankleyn
This is true only if you use SMS for 2FA.

For either method, you can audit the activity of your account on the GitHub
security page:
[https://github.com/settings/security](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.

~~~
eric_h
Interesting, I'd never checked that log before, and I just noticed a failed
login (though no two_factor_requested) from an IP address in Brazil.

I'm gonna change my password just in case.

------
ikeboy
I feel like sites should somehow preemptively disable passwords that have
leaked publically. Is there a simple way for them to do so without downloading
every leak themself? Is there a simple way for whitehats to help out? Whitehat
means you can't test the site without their permission, but someone could have
a database that they provide partial access to for sites without leaking and
spreading it further themself?

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?

~~~
anamexis
have i been pwned has an API:
[https://haveibeenpwned.com/API/v2](https://haveibeenpwned.com/API/v2)

~~~
bigiain
Troy doesn't (for very good reasons) keep the passwords or hashes from
breaches - just the email address. That make his API not quite capable of
doing what's proposed here - Github can't use Troy's HIBP API to detect
whether a breach containing my email address included a password that
authenticates with them. (And I'm not sure there's even a way to make that
service without creating _way_ more security problems than it solves...)

~~~
ikeboy
Do you see any blatant security problems with my proposal? The biggest problem
besides DOS is that it leaks passwords to the site, which may prevent this
from being useful except to trusted sites. But that can be solved by
hashing/salting before uploading to the site, as long as the site publicizes
their salting method (which shouldn't present security concerns, right?)

------
jrockway
I hadn't noticed that Github started supporting U2F. Nice to finally use my
keys for something other than Google accounts.

~~~
vulpino
Dropbox does too! Unfortunately, those are the only sites supporting U2F I
know of at the moment.

~~~
bojo
Bitbucket as well.

~~~
colemickens
That's new! Took more tries than normal to register, but that's great. They
took so long to roll out even TOTP based auth, I figured it would be ages
before seeing U2F.

------
arxanas
I got an email from Bitbucket earlier today warning me about unusual behavior
on my account as a result of reused credentials. Is it an attack across
several version-control services?

~~~
ThePhysicist
I got the same mail, seems like a coordinated attack. Luckily I had 2FA
enabled, I'd recommend everyone to do that as well as it protects your account
in these cases.

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.

------
ComodoHacker
This is far better than TeamViewer's response to the same threat lately.

~~~
lifehome
All I can see is panic for TeamViewer's incident.

------
Pyppe
Related to password security: any of you guys using Chrome's ability to sync
passwords to "Google cloud"?

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.

~~~
zamalek
There was recently a TeamViewer breach. Hackers somehow managed to access
people's machines. Everything was denied and it wasn't investigated.
Regardless, passwords were retrieved from Chrome. Some people lost a great
deal of money.

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.

~~~
praxulus
How would LastPass protect you against another TeamViewer breach?

~~~
lucaspiller
I assume it's the same with LastPass, but I use 1Password and that requires
you to enter a master password to unlock the passwords, where as Chrome
requires no extra authentication.

~~~
emodendroket
What do you mean? The whole thing can be encrypted with a master password, and
LastPass offers an option to simply remember your master password with the
browser extensions/desktop apps that I assume many people use.

~~~
elithrar
1Password, at least, does not offer a 'remember master password' feature. I
also configure it to auto-lock and auto-clear the clipboard on aggressive
timeouts (I suspect other password managers allow for this too)

~~~
infinite8s
How would that help with the aforementioned TeamViewer breach? Unless your
timeout is 1 min or less, the attacker can just watch and wait until you've
logged in somewhere with LastPass and then quickly act.

------
markokrajnc
Passwords became hard to manage... now you have to choose >>different<<
password for every site... Who can remember all those passwords? Only a
password manager...

~~~
austerity
Shameless plug time! Instead of remembering different passwords or using a
password manager (and thus storing all your passwords somewhere) you can use
[https://salty.pw/](https://salty.pw/)

~~~
anowlcalledjosh
Problem with this is when you need a password with a capital letter, or with
no symbols, or only 8 characters long.

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.

~~~
austerity
Yup, arbitrary restrictions on passwords are a bane. I've thought about adding
various modes but then you need to remember the mode you used. So far the most
sensible option seems to be falling back to a password manager for those
sites.

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.

------
tuna-piano
Anecdote: I use an email account and a relatively simple password (3
relatively common words together) on LinkedIn. I don't use that email account
much, but it was affected by the Linkedin hack. Today I get an email saying my
Twitter account was accessed suspiciously (same credentials).

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.

~~~
niij
You're using a dictionary password and subsequently reusing that password on
multiple sites.... and you're mad at LinkedIn for allowing your account to be
compromised? Umm.

~~~
Taek
You are blaming the victim. Yes, they could have taken more steps to protect
themselves, but those steps are inconvenient and cost everybody headspace and
headaches. And if we're all being honest we don't use best practice every time
we log into a website.

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.

~~~
ejcx
OP isn't blaming the victim. Op is playing with fire, KNOWS IT, and is
surprised when they get burned.

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.

[0] [https://www.w3.org/TR/credential-
management-1/](https://www.w3.org/TR/credential-management-1/)

~~~
Al-Khwarizmi
There are many solutions for password management, but any solution that can
work while travelling (in third-party computers), doesn't need a phone with a
data connection, and actually works?

~~~
anowlcalledjosh
KeePass2? There's a portable version that you can drop on a USB stick, and it
Works For Me™.

[http://keepass.info](http://keepass.info)

------
ledude
just a random tidbit.. but the system currently allows you to set your
password to what you previously had

~~~
emilong
I actually hope this is true as a consequence of them storing salted hashes
for passwords. That is, Github should not ever see my password, only validate
that I know what I entered previously.

~~~
e28eta
It's pretty easy to keep a list of old salted hashes, and copmare the new
password's salted hash against the previous ones. It doesn't require saving
the old passwords.

~~~
ikeboy
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.

~~~
niftich
I don't follow what you're saying.

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.

~~~
ikeboy
If everything is done server side, sure.

~~~
niftich
Why wouldn't it be?

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.

~~~
ikeboy
>Why wouldn't it be?

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.

~~~
icebraining
I don't see what hashing on the client gets you.

~~~
ikeboy
>So that the server never gets any plaintext.

Mitigates attacks that exploit the server but not the served js.

See also [https://security.stackexchange.com/questions/53594/why-is-
cl...](https://security.stackexchange.com/questions/53594/why-is-client-side-
hashing-of-a-password-so-uncommon) 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?

~~~
icebraining
Since the resulting hash must be deterministic, you can't use a salt, and
since you may login from crappy smartphones without JIT engines, you can't use
many rounds. So the resulting hash will be trivially cracked using rainbow
tables. The problem of variable-length passwords is better solved by only
allowing the use of block ciphers in your TLS configuration, which you should
probably do anyway.

As for the disadvantages, it makes logins take longer, forces the use of
JavaScript, increases the complexity of code and increases the site size.

~~~
ikeboy
>Since the resulting hash must be deterministic, you can't use a salt

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).

~~~
tokenizerrr
> 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.

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.

~~~
ikeboy
If you're using different salts for each password and sending them from the
server each time (the first option above), then my point still applies: the
client would need to send the same password hashed to different salts, which
may weaken security guarantees. (I don't know if any hash algorithms could be
exploited using this, though.)

------
brador
Why not do a site wide reset on every account?

~~~
finnn
Probably because the only accounts that were compromised were those dumb
enough to use the same password on multiple sites, and one of those sites to
be compromised.

------
akerl_
"We immediately began investigating, and found that the attacker had been able
to log in to a number of GitHub accounts."

~~~
jlarocco
Did you even read what the OP asked?

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.

~~~
dang
The site guidelines
([https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html))
ask you not to post did-you-even-read comments to HN:

 _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.

