Hacker News Reader

Comment by ericabiz | Hacker News Reader

They're asking people to revoke Buffer as an app: https://www.facebook.com/bufferapp/posts/566007046805080

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

View on HN

Wow that's terrible, I guess it means they stored their access tokens with no encryption.

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.

> I guess it means they stored their access tokens with no encryption

Or the encryption key was on a system the hacker may have accessed.

Yeah, same thing. I remember a large retailer I did some pentesting for a long time ago, they kept the encryption key for credit card numbers in the same table as the card numbers. Doh.

Maybe I am misunderstanding, but how is it possible to encrypt the access token? Doesn't the server need it in plaintext to make requests?

If the web server is making API calls, encryption could still protect you from some SQL injection attacks, even if the decryption key for all tokens was in the web app code.

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.

Remember encryption is not the same as hashing :) With encryption you can reverse the process, as long as you have the encryption key(s). With hashing, you can't.

I realize, but whatever server is making the API calls needs unrestricted access to the key and the encrypted tokens. So if server is compromised, the access tokens are necessarily compromised too, aren't they?

people love buffer

we'll re-invoke it

Unfortunately not everyone is as forgiving.

That said, HN pathologically overestimates the impact of mistakes that companies make. It probably won't be as bad as people say here.

True. In the end, they'll lose a LOT of free users who won't bother to reactivate Buffer. A good % of paid users might stay. Hell, that might even be a net benefit - less resources to devote to supporting the free users.

I will certainly use Buffer App again. For the same reason I used Buffer App before this incident. That might be easier because my accounts were not affected. In addition, the Buffer App team seems to be working hard to resolve the incident. Security issues are unpleasant but unavoidable.

Yup, I'll keep using it. By advising users to revoke access they're clearly putting user safety ahead of their corporate metrics. That shows that they have their priorities straight and are worth working with.

Reply on news.ycombinator.com