
Disqus Security Alert: User Info Breach - sashk
https://blog.disqus.com/security-alert-user-info-breach
======
electic
This is a good time to remind everyone to use a password manager and to have
each password generated. Each service should have it's own password so if it
gets compromised, your exposure is limited to that one service.

It is clear this is going to be a staple of internet life, so might as well be
prepared.

~~~
jMyles
Can you suggest a good password manager?

Ideally, I'd really like something that's deterministic - ie, I can provide a
seed, and then that seed plus the domain name becomes the basis for the
password.

That way, it's trivial to recover passwords when sitting at a new computer.
And I imagine if the seed is sufficiently long (say, a 10-word sentence that
includes 2 or 3 non-dictionary words) then it'd be highly impractical to
force.

Right?

~~~
comex
A better argument against deterministic password generators than the current
replies to your post is that if you have to change your password on a given
site - due to password expiration, ‘forgot password’, security breaches, etc.
- you have to change the seed, and remember which seed you’re using for which
site.

There are some others:

[https://tonyarcieri.com/4-fatal-flaws-in-deterministic-
passw...](https://tonyarcieri.com/4-fatal-flaws-in-deterministic-password-
managers)

But if you want to use one anyway, that blog post links to a bunch of them.

~~~
jMyles
Ahh, thank you. This is the kind of refutation I need. I'll read up and
decide.

As for your specific qualm: I have to imagine that this can be solved by
adding a numerically-determined nonce (so that I can say, "this is my 2nd
password on disqus", etc) without having to fashion a new key.

edit: OK, so I have read the article. Here are my reactions to the author's
four concerns:

* #1: Password schemes

> Unfortunately, sites have wildly varying and often conflicting password
> requirements: non-alphanumeric symbols are mandatory! Passwords must be
> alphanumeric only! Capital letters required! Passwords must be lower-case
> only! Passwords must be at least 12 characters long! Passwords must be at
> most 8 characters long!

> While many of these requirements seem silly and in a perfect world all sites
> would adopt the new NIST password guidelines, reality is messy and there is
> no single deterministic password generation scheme which can accommodate the
> password policies of all sites.

There aren't _that_ many different schemes. Maybe a grand total of three
dozen? I think that the program can simply have a user-updated registry
(perhaps that's shared) of schemes, and the generator accounts for this. This
seems like... maybe 150 lines of Python.

#2) Revocation and new passwords

> We could ask the user to remember the site-by-site counter and input the
> correct counter value to derive the correct password. But I think this is
> silly.

Umm, that's a strange argument. I don't think that's silly. I think it's
highly practical. Currently, users remember a shitload of different details
for different domains, including different usernames (this one was taken here,
that one didn't meet the scheme there, etc) and often slightly different
passwords.

Making them remember an integer that will rarely be larger than 3 instead of a
password seems awesome. Worse case scenario, they can keep trying until they
get the right one.

> You can’t store credit card numbers or bank account numbers in such a vault.

> You can’t put arbitrary cryptographic keys in such a vault.

> You can’t store randomly selected answers to security questions in such a
> vault.

> I consider this to be part of the basic functionality of a password manager.

I don't know what to say except that... I don't. I'm happy to have a password
manager literally just manage passwords and allow me to use other tooling
(like form memory in a browser) for this other stuff.

> Exposure of the master password alone exposes all of your site
> passwords...If you accidentally type or paste your master password into
> email, IM, or social media, an attacker can leverage that alone to derive
> all of your site-specific passwords.

Yeah, I get it - that's the same argument the others in this thread are
making.

But I'm not going to accidentally type along seed, like a 10-word sentence
with punctuation, into any of those places. This seems like a completely
absurd argument to me.

~~~
Arcsech
That's effectively no different from changing the seed data (say, going from
"password1" as the seed to "password2"), you still have to remember which
iteration you're on on each site as part of the seed data.

Edit: and this point is actually made in the article the GP linked.

------
cristoperb
I just learned about this thanks to an email from
[https://haveibeenpwned.com/](https://haveibeenpwned.com/) alerting me that my
account info was leaked.

~~~
kakkun
I got an email too. The thing is, I don't have a Disqus account. The only
mention of Disqus in my gmail account is the haveibeenpwned email. Any idea
what's going on?

~~~
simoncoggins
Same happened to me. I think I may have used the social media login via
Google, which I'm guessing could get your email into the leak without any
password being present.

------
tptacek
_Right now there isn’t any evidence of unauthorized logins occurring in
relation to this. No plain text passwords were exposed, but it is possible for
this data to be decrypted (even if unlikely)_

Where by "unlikely" we mean "with almost complete certainty".

~~~
jlgaddis
That was my first thought upon reading that. Someone at Disqus should take
those lists of hundreds of millions of hacked passwords, hash 'em with SHA1,
and see how many _aren 't_ in their own list.

~~~
bradknowles
You mean, like Troy Hunt, of “haveibeenpwned” fame?

------
throw2016
We just have to concede centralization is a dark pattern online. Its creates
incentives for obsessive profiling, surveillance and makes a complete mockery
of privacy.

In many ways the old world of dispersed forums were much better and are still
better content wise than anything Reddit can throw up.

You can share photos and remain connected to family and friends without
needing anything like facebook. This kind of centralization only favours self
promoters and exhibitionists and shifts tremendous personal data patterns to
entities who have no business having or analyzing this data. No one should
have access to this kind of data as the consequences can only be negative.

------
syshum
This highlights an important aspect of Data Security that is often never
talked about

Data Minimization.

It seems they had a old copy of the database, likely a backup, just sitting
around somewhere. The question is why did this old copy, from 4 years ago,
still exist. Why was it not deleted under a standard data retention policy.

Companies not only need to spend time on how they will secure data, they need
to spend time on how they will age out and delete old data.

~~~
CaptSpify
We really need to get companies to see user data as a liability, rather than
an asset. Our incentivisation system is completely backwards for this.

------
stevenj
The rate at which these security breaches are happening is very alarming to
me.

I don't know what the effects are of them (including this one), but my gut
tells me they'll only increase over time; perhaps the severity of them as
well.

It's honestly making me re-consider my use of the internet, technology, and
electronics.

What's the future hold with regard to security, breaches, and keeping our data
and information safe?

~~~
jacquesm
> The rate at which these security breaches are happening is very alarming to
> me.

It is the rate at which they are being published that is alarming to you, the
rate at which they are actually happening is much higher still.

------
subcosmos
SHA1..... That's bad

Current gpus can hash tens of millions of passwords per second with SHA-1.

~~~
Ajedi32
Some back of the envelope calculations...

[A GTX 1080 can do ~8.5 billion hashes/second][1].

An 8-character, truly random password with mixed case, numbers, and symbols
has (26 * 2+10+32)^8 possible combinations.

That means an attacker with a single GTX 1080 could crack such a password ((26
* 2+10+32)^8/2) / (8538.1 * 10^6)) seconds ([approximately 4 days][2]) on
average. And most user's passwords are most certainly not truly random (i.e.
they're significantly weaker than that).

[1]:
[https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...](https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40)

[2]:
[https://www.wolframalpha.com/input/?i=((26*2%2B10%2B32)%5E8%...](https://www.wolframalpha.com/input/?i=\(\(26*2%2B10%2B32\)%5E8%2F2\)+%2F+\(8538.1+*+10%5E6\)\)+seconds)

------
cyberferret
I am always puzzled when a company reports a breach and says "X account
details were compromised, and Y passwords were obtained..." when Y is a
smaller percentage of X.

I would assume that there is always a 1 to 1 relationship of user account
details to passwords, or that the passwords are stored within the user table
in the DB, so at best, X=Y at all times?

I can understand if it is a current breach and the DBAs managed to stop a
transfer of data mid query, but in a 4 year old database (in this case) where
only hackers only have partial data for passwords, but full data for user
accounts?

~~~
Ajedi32
Disqus provides options for single-sign-on. So it's possible that some of the
accounts breached didn't have a password associated with them, only OAuth
tokens.

------
avishai2112
How can an independent security researcher be aware of such a breach ?

~~~
jlgaddis
One guy in particular, I can't recall his name (Chris Vickery, maybe?), has
been behind _A LOT_ of these "discoveries"; specifically, a bunch of Amazon S3
buckets that are misconfigured (WRT permissions) and wide open to anyone who
wants to download the data. (I'll admit that I'm kinda curious as to how he
enumerates all of them!)

Based on the little information published, it sounds like that's what has
happened in this case as well.

The same guy has also found tons of wide open MongoDB instances and such.

The guy you're referring to, Troy Hunt (HIBP) , writes about these cases but,
AIUI, doesn't typically find them on his own. He's usually notified by the
actual "researcher" \-- this Chris guy in a lot of recent cases -- and they
share the info with him.

~~~
graystevens
You can enumerate S3 buckets (and other cloud operators) by DNS bruteforce, or
looking at how the company name them on their website and working through some
common name.

Did this recently and found 1000’s of public buckets.

------
kylehotchkiss
All these leaks are making me feel anxious to go around deleting anything I no
longer use and be more careful about signing up for anything without FB/Google
login. It seems like only giant companies have the competence to maintain
security BUT even then, Yahoo proves me wrong on that one.

That said, I'm sort of happy 1password switched to subscription billing -
hopefully this lets them pay top dollar for the best security experts.

~~~
Ibethewalrus
Someone posted on HN fastmail includes a very unusual and nice way to stop
spam using alias, basically it's mailinator baked in:
[https://www.fastmail.com/help/receive/aliases.html](https://www.fastmail.com/help/receive/aliases.html)

~~~
nathanaldensr
I pay for FastMail for this very reason. When I transferred off my Google Apps
email account, I set up a unique ___@ for every website. If my email ever
leaks, I'll know who leaked it (or sold it).

~~~
rhblake
Same here. I simply set up a catchall alias so <anything>@somedomain forwards
to foo@regulardomain; very convenient. The fact that FastMail supports
multiple custom domains, at least with standard accounts, is also nice -- even
more so since you can (optionally) use their own nameservers and set up
whatever DNS records you want (I use that for some personal websites), while
they make sure SPF/DKIM records are always correct.

(Having a separate domain is not really necessary, but I registered it through
nearlyfreespeech.net and use their WHOIS privacy service; at least J. Random
can't easily figure out my identity based on the email address alone).

------
slvrspoon
It's not just your passwords of course but also email and sometimes phone and
credit cards you have potentially stored at sites as well.

------
bobwaycott
Is the info available online somewhere? I’m curious what my password was in
2012.

------
jlgaddis
Sounds like somebody left an S3 bucket wide open yet again.

------
pussypusspuss
SHA1 hash? You’ve gotta be fucking kidding

~~~
sergiotapia
It's from a database from 2012. Wasn't that cutting edge in 2012? What kind of
sick shit will we be encoding our stuff 6 years from now, that bcrypt will
seem laughably ill-suited.

~~~
tptacek
The most popular post that ever ran on Matasano's security blog was the one
where I encouraged people to migrate to bcrypt. In 2007. Bcrypt, of course, is
much older; Niels and David invented it as the standard password format for
OpenBSD back in 1999 --- and bcrypt was a response to FreeBSD's _iterated_
salted hash format, which also had a work factor, and is years older still.

Today, in 2017, bcrypt remains a sound recommendation. You can do better, but
for password databases on websites, not _materially_ better.

Salted SHA-1 hashes (salted SHA-anything hashes) were malpractice in 2012.

~~~
bobwaycott
> _You can do better, but for password databases on websites, not materially
> better._

Do you mean using scrypt? What do you mean by _materially_ better?

~~~
tptacek
No, I mean bcrypt.

Scrypt is better than bcrypt, but mostly not in ways that make much of a
difference in 2017.

PBKDF2 comes close to being materially worse than bcrypt and scrypt, because
it's especially straightforward on modern hardware, but _even PBKDF2 is fine_.

For the most part, as long as you're using anything with a KDF-like design for
your password hash, a compromise of your password database is going to reveal
the very terrible passwords and only those passwords; the rest will be too
costly to crack.

Right now given the choice I'd use scrypt and go slightly out of my way to get
it (if there was a good 3rd party library for it and bcrypt was in the
standard library and I was like a "yarn add" away from having it, I'd take
that step), but I would _not_ convert a bcrypt site to scrypt.

~~~
borplk
Considering that PBKDF2 has adjustable difficulty parameters would you still
say it's worse if very high difficulty parameters are chosen?

~~~
dchest
It has to do with defender's vs attacker's costs. PBKDF2, which is usually
instantiated with SHA-2, even with huge amount of rounds is still a lot
cheaper for the attacker than for the defender, since the attacker can use
GPU/ASIC, requiring fewer transistors, running many calculations in parallel,
while defenders usually use CPU. On the other hand, bcrypt, scrypt, Argon2
don't provide a lot of advantage to the attacker compared to CPU, since GPU
and ASIC implementations are expensive and memory-bound.

PS My measurements show that pure JavaScript implementation of scrypt is
better than fast native PBKDF2 provided by WebCrypto API or Node.js at the
same running time.

PPS But yeah, if you can't use bcrypt/scrypt/Argon2, but can use PBKDF2 with
high number of rounds, sure, do it.

------
foxhop
Was the salt leaked?

~~~
nathanaldensr
Another important question: Did they use a unique salt _per password_? Their
announcement is ambiguous.

~~~
Ajedi32
That's the general idea of a salt, yes. I'd argue that a salt which isn't
unique per-user isn't really a salt at all.

