Ask HN: Buffer got hacked - does anyone know details?
It seems like @buffer got hacked.
https://twitter.com/search?q=%40buffer&src=typd&f=realtime
The guys seem to be on it.
Last information: They confirmed they got hacked turned of publishing and they are investigating the issue.
82 comments
[ 2.8 ms ] story [ 87.8 ms ] threadbuffer rocks and is handling this in an A+ way
Buffer is handling this well, and will continue to get my business.
Source: https://twitter.com/buffer/status/394182270522646529
- All FB posts via Buffer are temporarily deleted. They will reappear again once we've enabled the FB app again (which we'll do once we're sure we're not compromised anymore).
- All Tweets are also stopped from sending.
We'll keep you updated from the @Buffer twitter and FB account.
- Leo
How do you store the Buffer passwords? SHA1(password+salt)?
Edit (T+7 minutes): Rewritten to not be a jerk.
How To Safely Store A Password http://codahale.com/how-to-safely-store-a-password/
This is exactly why they are not particularly well suited to passwords. A brute-force attack (since you're salting your passwords I'm sure!) against them isn't a huge undertaking. Just with the equipment in the computer I'm on right now, I'm looking at generating about 11.5b MD5 hashes per second, or 3.1b SHA1 hashes per second.
At eight characters a-zA-Z0-9, I'm looking at about 5 and a half minutes to brute force every combination with MD5. Under a day for SHA1.
Hashes like bcrypt and scrypt, on the other hand, are designed to be slow. Their complexity factors actually provide means to slow the hashes down even further as hardware becomes faster. Instead of 11.5b/second, you can increase the complexity until you're only able to generate one hash per second... Now it takes you over three and a half centuries to hash what might take one second with MD5.
Even ignoring the possibilities of MD5/SHA1 being 'broken', they're simply too fast to be considered for hashing passwords.
(Estimates of GPU hashing speed taken from http://golubev.com/gpuest.htm).
[1] http://xato.net/passwords/more-top-worst-passwords/
Therefore 1) it is not useless to not increase your storage security even if Y% of your users use bad passwords as you are protecting 100%-Y% of you users. 2) Y% is probably not 99.8% for you, and if you are worried about it you can take steps to mitigate the problem.
ps. He is ignoring punctuation which is an important detail for actually doing the cracking.
pps. I appreciate the sentiment (users choose shitty passwords) but not the conclusion (so don't bother storing them well). The proper conclusion is use scrypt/bcrypt and increase the work factor. You can take reasonable steps to protect your users and you should.
Just to clarify: my original point wasn't that you should continue using md5. Rather, it was that bcrypt doesn't improve your security much. Given the problems with the 99.8% figure, it would be better to say, "the extra security that bcrypt provides might be less than you expect".
[1] https://xato.net/passwords/how-i-collect-passwords/
Every little bit helps.
How'd they get into your system? Was it a Buffer Overflow?
Brutal. Once you revoke it, there's little to no chance that you're going to re-invoke it.
I've seen stuff like this get ugly in the past [1] -- I really like and respect the Buffer founders and hope they can recover from this.
[1]: http://en.wikipedia.org/wiki/Gnolia
we'll re-invoke it
Personally feeling slightly smug now, I actually applied for a job there not too long ago and got a half hearted rejection without any feedback (or the courage to actually reject me). I have direct experience in doing security for a Facebook SPMD - we never got successfully hacked, and yet we ran scenarios like this in our mind all the time.
Or the encryption key was on a system the hacker may have accessed.
With a system of this scale, the web server will probably be making no API calls, as everything might be sent via some distributed system.
There are, anyway, many solutions to store the keys, a key vault that is separate from both database and application/web servers would be ideal.
There's not much to do if an attacker gains control of every machine, so the general idea is to keep every attack vector as isolated as possible.
http://www.davidreiley.com/papers/SpamEconomics.pdf
One thing that drives me nuts about that paper format (a LaTEX template, I guess) is that it doesn't have a date. And this happens a lot. If the topic was an abstract mathematical concept, evergreen and timeless, then the date isn't so important. But a paper about spam that is vague on the date? I don't understand. That field is always changing, and I presume the economics are changing, too.
http://www.davidreiley.com/papers/SpamEconomics.html
Hi there,
I wanted to get in touch to apologize for the awful experience we've caused many of you on your weekend. Buffer was hacked around 1 hour ago, and many of you may have experienced spam posts sent from you via Buffer. I can only understand how angry and disappointed you must be right now.
Not everyone who has signed up for Buffer has been affected, but you may want to check on your accounts. We're working hard to fix this problem right now and we're expecting to have everything back to normal shortly.
We're posting continual updates on the Buffer Facebook page and the Buffer Twitter page to keep you in the loop on everything.
The best steps for you to take right now and important information for you:
Remove any postings from your Facebook page or Twitter page that look like spam Keep an eye on Buffer's Twitter page and Facebook page Your Buffer passwords are not affected No billing or payment information was affected or exposed All Facebook posts sent via Buffer have been temporarily hidden and will reappear once we've resolved this situation I am incredibly sorry this has happened and affected you and your company. We're working around the clock right now to get this resolved and we'll continue to post updates on Facebook and Twitter.
If you have any questions at all, please respond to this email. Understandably, a lot of people have emailed us, so we might take a short while to get back to everyone, but we will respond to every single email.
- Joel and the Buffer team
All updates have been paused.
Passwords and payment information have NOT been compromised. --
It would be sorted out in a bit.
(I will be re-enabling ASAP - I use this app a lot!)
We're working pretty hard to get to the bottom of everything.
Let me know if you have questions, I'll try and answer them all.
When I see a local credit union site written in VBScript get hacked, I don't worry too much because it was probably riddled with SQL-injection bugs that any script kiddie can exploit. However, I know that you guys take data security seriously (you and I Skyped a while ago) and yet this happened. That's what worries devs like me the most.
I think it would be very helpful to us all (including many of your tech-savvy users) if you would write a detailed blog entry describing what actually happened and how. I believe you're encrypting tokens now but how did they get exposed in the first place? Was it a framework issue? Unhandled exceptions? Wrong chmod on a log file? New employee hooking up trojan'ed PC to your internal network? Here's hoping you feel comfortable in sharing.
Though I don't want to be crass, I can't help but mention that I'm working on a project to help minimize the damage from these sorts of things. Would be interested in any feedback. (http://socialsecurity.io)