Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Unless the web site was paranoid enough to encrypt your password client-side before sending it to the server, it's possible the password was leaked.

With 2FA, your password and a one-time code were leaked and cached somewhere, but in order to log in as you today, an intruder would need to know a new code. And they wouldn't, unless you happened to set up your time-based one-time password (TOTP, e.g. Google Authenticator) during this timeframe as almost_usual mentioned. The reason here is because it's possible the secret key was leaked, so now someone can generate the same numbers your app is generating.

xuki mentions that 2FA doesn't protect you against stolen bearer tokens, which is another issue. The usefulness of a stolen token depends if it's expired or not. If you haven't, force a signout of all your sessions to invalidate old tokens (and change your passwords).



What is the timeframe where setting up TOTP is vulnerable? I haven't been able to find an indication of how long this bug has been in production.


Cloudflare shares a timeline on their blog post:

  The three features implicated were rolled out as follows.
  The earliest date memory could have leaked is 2016-09-22.

  2016-09-22 Automatic HTTP Rewrites enabled
  2017-01-30 Server-Side Excludes migrated to new parser 
  2017-02-13 Email Obfuscation partially migrated to new parser 
  2017-02-18 Google reports problem to Cloudflare and leak is stopped

  The greatest potential impact occurred for four days starting
  on February 13 because Automatic HTTP Rewrites wasn’t widely
  used and Server-Side Excludes only activate for malicious
  IP addresses.
https://blog.cloudflare.com/incident-report-on-memory-leak-c...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: