4 ms·

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

They're asking people to revoke Buffer as an app: https://www.facebook.com/bufferapp/posts/566007046805080 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 http://en.wikipedia.org/wiki/Gnolia

dylanhassinger 13y ago
people love buffer we'll re-invoke it
- AznHisoka 13y ago
  Unfortunately not everyone is as forgiving.
  - jamesaguilar 13y ago
    That said, HN pathologically overestimates the impact of mistakes that companies make. It probably won't be as bad as people say here.
    - AznHisoka 13y ago
      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.
  - chmars 13y ago
    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.
- edraferi 13y ago
  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.
mpeg 13y ago
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.
- dangrossman 13y ago
  > 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.
  - mpeg 13y ago
    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.
- shawnz 13y ago
  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?
  - mpeg 13y ago
    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.
    - deleted 13y ago

dylanhassinger 13y ago

people love buffer we'll re-invoke it

AznHisoka 13y ago
Unfortunately not everyone is as forgiving.
- jamesaguilar 13y ago
  That said, HN pathologically overestimates the impact of mistakes that companies make. It probably won't be as bad as people say here.
  - AznHisoka 13y ago
    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.
- chmars 13y ago
  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.
edraferi 13y ago
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.

mpeg 13y ago

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.

dangrossman 13y ago
> 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.
- mpeg 13y ago
  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.
shawnz 13y ago
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?
- mpeg 13y ago
  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.
  - deleted 13y ago