
Hack of MacRumors forums exposes password data for 860,000 users - coloneltcb
http://arstechnica.com/security/2013/11/hack-of-macrumors-forums-exposes-password-data-for-860000-users/
======
kijin
I really, really, really wish that GoPHP5 Round Two [1] takes off and all the
popular blog & forum programs get on board.

PHP 5.3.7 is the first version of PHP that is _guaranteed_ to come with a
proper implementation of bcrypt. All versions before 5.3.7 either don't
support it at all, depend on the OS to support it, or have the wrong
implementation. phpass won't help you; it just produces a weaker, "portable",
md5-based hash, as it does in WordPress by default.

As a result, no open-source blog or forum program that needs to support PHP
versions lower than 5.3.7 can use bcrypt by default. Since the world isn't
going to abandon PHP any time soon, the only option is to force every web
hosting company to upgrade PHP to 5.3.7 or higher.

[1] [https://groups.google.com/forum/#!topic/php-
fig/ogp03OHbVJ0](https://groups.google.com/forum/#!topic/php-fig/ogp03OHbVJ0)

------
ecesena
Disclaimer: I'm biased towards security.

I can't understand the superficiality in doing security-related activities
(not being hacked of course, but the leakage of passwords because of
md5+salt...).

Or better, I can understand that security is not priority 1 when one launches
a new product, but there should be periodic reviews, similarly as reviews of
the ux/ui, the branding/communication, the algorithms...

Someone should make a good post like: you can launch a website without x, y,
z. When you reach 1k users, you need to implement x. At 10k you must have y.
You can't think to 1M users without z.

~~~
kijin
MacRumors didn't design their own password storage scheme, they just used the
popular VBulletin forum software. I don't think it makes sense to ask people
to switch forum softwares when they reach a certain number of members.

It may or many not be VBulletin's fault that the site was hacked in the first
place, but it's definitely VBulletin's fault that it uses md5 by default.
Absolutely no excuses there, since supporting PHP 4.4 is not a valid excuse.
The only fault of MacRumors operators that I can think of is that they used a
vulnerable piece of software.

Unfortunately, forums aren't cool anymore, so few people write them anymore
and it's difficult to find forum software that meets modern standards.

~~~
ecesena
It's not the point who the fault is, it's that if MacRumors/VBulletin grows
the amount of users, they (jointly, the former, the latter) need to take into
account security.

~~~
josteink
So you are saying at a certain point they should security-audit the software
they run on.

At what point does that mean the source of the PHP forum-software? At what
point does that mean the source of PHP itself? On what point does that become
the source of the operating system PHP runs on?

Add to this any other component involved which may or may not expose a
security-risk, like MySQL, Email-servers, etc.

I think while your attitude may be the right one, your statement is overly
simplistic.

~~~
fredsted
Making sure the password hashing mechanism is secure would be a good starting
point...

------
FiloSottile
Question: why half of the salt isn't hardcoded in the application code? That
would make a database access completely useless without a deeper penetration,
and it's really easy to implement.

~~~
kijin
A hardcoded second salt is called a _pepper_ , and some programs use it.
Unfortunately, with a popular and outdated PHP app like VBulletin, it won't be
too difficult for an attacker to obtain both the DB dump and whatever
configuration file that contains the pepper. All those PHP files just sit
inside the document root, and everyone knows exactly where they are.

------
ghshephard
Obligatory: [http://codahale.com/how-to-safely-store-a-
password/](http://codahale.com/how-to-safely-store-a-password/)

------
cottonseed
How many times does this have to happen before we realize passwords are a
terrible authentication method? It is ridiculous.

~~~
willvarfar
The alternative you'd put forward is?

~~~
eknkc
I'd like my phone to ask for some pin or my fingerprint when I want to login
something. No username, password or anything. Like bluetooth pairing, I'd pair
my phone with services that I register and they could trigger my phone to ask
my confirmation.

~~~
bigiain
That sounds just like TOTP.

I use Google Authenticator on iOS and Android. It's just a standards-compliant
(RFC 6238) TOTP app, not anything Google specific. I've got six logins using
it - gmail, Dropbox, Amazon (AWS), Github, Digital Ocean, and an internal
service.

One thing that is a bit badly done - and I understand why - is making it easy
to have "redundant duplicates". When setting up a new TOTP three factor auth
account, I need to get my iPhone, iPad, and Android phone all together and
manually type in the seeds (or QR code them) to all three to ensure I'm not
completely screwed if I lose the only device with the magic tokens…

I'd love to have more of my important stuff secured with TFA/TOTP.

------
ohwp
The MD5 passwords are not the issue here. The main issue is that the hacker
logged in with the admin credentials.

Ofcourse the passwords should be encrypted but what about all the other data?

So the question is: should we store all data encrypted? Because it's not if,
but when will the data get exposed.

------
sciguy77
Oh crap, I have an account with them…

------
conformal
it confirms that most mac users have extremely short passwords (airhorn)

-> the mac user

------
runn1ng
md5+salt.... that isn't so terrible, is it.

~~~
ecesena
It is, in fact.

hash(pwd) -> attacker can build a rainbow table and password cracking becomes
a table lookup. Required storage depends on the length of the hash value, and
md5 is only 128 bits.

hash(salt|pwd) -> no rainbow table because of salt. The attacker can use a
dictionary attack. Time depends on how fast she can compute the hash, and
again md5 is pretty fast.

Solution:
[http://en.wikipedia.org/wiki/Key_stretching](http://en.wikipedia.org/wiki/Key_stretching)

~~~
runn1ng
Well, it's worse than bcrypt/scrypt, but it's still not primitive md5/sha
without hash, or just symmetric encryption as in Adobe...

~~~
bigiain
"Worse than", as in "six orders of magnitude worse than"

Hashcat on a single PC (with an appropriate video card) can test over 5
_billion_ passwords/second, and salted MD5 passwords barely slow it down at
all (the Joomla result below is for MD5(password + 32CharSalt)). The salt
helps, because I can't just look the hash up in a rainbow table (or google for
it), but you should expect any password to have ever been made public from any
other exploit to be on somebody's wordlist and to fall in seconds to any
attacker with a few hundred bucks worth of video card, and any combo of two or
three dictionary words with or without obvious letter-number substitutions to
fall in well under an hour.

With bcrypt, that comes down to under 4 thousand attempt per second. That
makes password cracking one million times harder.

from [http://hashcat.net/oclhashcat-plus/](http://hashcat.net/oclhashcat-
plus/)

    
    
      MD5: 5144M c/s
      Joomla (MD5): 4609M c/s
      bcrypt: 3788 c/s

~~~
bigiain
I see from another comment that vBulletin uses MD5(MD5(password)+salt) - I'd
expect hashcat to be able to still blast through that at something north of 2
billion c/s…

That'll search the entire 32million entry list of Rockyou passwords in under a
tenth of a second, and all 9-lower-case-letter passwords in an hour - or two
hours if you include all 9char combinations with a single leading uppercase
char. The rulesets that hashcat can use almost certainly means that any admin
password which was human-created and under about 20 characters in that leak
has already been cracked (anything made out of names or dictionary words with
guessable letter/number/punctuation substitutions and leading/trailing digits
- M1ffyTheC@t is not unguessable)

~~~
InclinedPlane
Modern password cracking is really quite sophisticated. They've taken to using
words and phrases from common websites such as wikipedia in addition to
ordinary words.

~~~
bigiain
You really can't manage passwords in your head any more. At least not enough
of them.

In my head I've got three banking passwords, two domain registrar passwords,
and one "important email account password" (which is backed with TFA) that's
the email that password resets get sent to - all are 16 random chars, and also
two five word GPG passphrases. Those are _only_ in my head (well, one GPG
passphrase is also in a sealed envelope in work's safe). Everything else is in
1Password locked behind a 7 word (intentionally misspelled) pass phrase –
there are right now 866 sets of credentials in there - mostly 16 or 25
character (depending on when they were created/updated) random
upper/lower/digits/special strings - with a few exceptions where
sites/services won't let me use 25char passwords or sometimes prohibit
"special characters" (Like your slow cryptographically secure hash function is
susceptible to SQLi or XSS? That's why I can't use quotes or angle brackets?
Really? Or are you actually incompetent?)

The 1Password file is synced between 4 machines in two physical locations plus
3 mobile devices, and time machine archived on one machine in both physical
places - and one of those time machine archives is EncFS encrypted and stored
on Dropbox and archived on S3 weekly, the other is daily rsynced to a pair of
local drives. The passphrase isn't written down anywhere - but a hint which'd
remind _me_ of the passphrase but would be innocuous/meaningless without
sufficient context is written down and safely stored in two places. I _would_
be screwed without my 1Password data.

In my more paranoid moments, I wonder if both EncFS and 1Password's encryption
is reliable enough to make leaking that file to Dropbox (which means
S3/Amazon, which means the NSA if they're ever curious enough to ask Dropbox
and/or Amazon for it). I also wonder about the attack vectors I've opened by
having the 1Password file and app on two iOS devices - potentially leaking
them to Apple and hence the NSA. But if the NSA ever come looking at _me_
specifically, I'm going to assume I've lost everything already. I don't
_think_ any of that'll get caught up in dragnet surveillance though (except
for when I get clients asking me to mail them hosting/admin/registrar
credentials to their gmail or yahoo email addresses - _facepalm_ )

(Actually, I also have my AppleID password "in my head" \- since I need to
type it in too many places where 1Password can't autofill it for me...)

------
kevinxucs
great, just fucking great, first adobe, then macrumor, how many times do I
need to change password in a single month

~~~
nwh
Stop using one password for everything then. A manager like 1Password is
almost an essential tool for the security conscious.

~~~
hiby007
are these services safe?

~~~
chattoraj
Don't know about 1Password, but LastPass encrypts all passwords client-side.
Only marginally less safe than storing passwords in an encrypted file on your
personal machine.

~~~
kenjackson
Or use KeePass. And you can store the KeePass database on DropBox.

~~~
yaeger
I use KeePass. It's great. I looked at LastPass but I didn't like that it is
"Browser Based". I know it is supposed to be working "offline" but somehow I
felt safer using KeePass where I can use the programs own UI, make sure the
exe doesn't "phone home" and where I can directly see the encrpted db file and
do with that as I please.

At first I worried about what would happen should the db file get corrupted
somehow. But then I set up the backup tools with which I can keep as many
backups in as many places as I want, so unless the db file gets corrupted in
_all_ places, I think I will be fine.

