Hacker News Reader

Comment by StavrosK | Hacker News Reader

I would like to point out that, if most sites used two-factor authentication, this leak would be at most a minor inconvenience. Maybe we should push for that more. Just days ago I talked to Namecheap about its horrible SMS-only 2FA and asked them to implement something actually secure, maybe contact your favorite site if they don't have 2FA yet.

View on HN

If you setup TOTP (Authenticator) while this bug was out in the wild your shared secret key could have leaked. SMS would actually be safer than TOTP in this scenario.

That's insightful. So you shouldn't only reset your passwords, but your TOTP setup too (if you set it up in this period).

I think it's a flaw of TOTP though. The client secret should be client generated and should never leave the device.

Yes, unfortunately both the client and server need to have that shared private key to generate the same codes.

Transmitting the key over a 'secondary' channel would have protected people here.

It begs the question of whether or not TOTP is really 2FA if it is setup using a single channel of communication.

What ? No, that shouldn't be possible (unless the site operator massively fucked up, or there's some attack that feasibly lets you go from one or more TOTP values to the likely shared secret).

TOTP works by having (as you said) a shared secret key, and both sides calculate an HMAC of the secret along with the timestamp, and then just modulo the resulting HMAC by 10^6 (usually, for TOTPs with six digits).

Your google authenticator (or whatever) app does this HMAC on the shared secret + time, you type in six digits, and the other side does the same HMAC and verifies that they're the same. If they're UX-conscious, they might decide to HMAC the previous and next 30 second periods as well and compare those too, to account for small amounts of time skew.

parent said "if you setup TOTP". If you did that, you somehow communicated the shared secret key to your authenticator, presumably from a web page. Which could have leaked.

ah, thank you, that makes more sense.

2FA doesn't protect you against cookie/token stealing. The website owners need to invalidate all of that on their ends.

It does and you don't even need real 2FA for it.

Any non-trivial auth token comes with device or host fingerprinting. That's enough to stop this attack scenario in most cases.

Usually only the big tech companies and well-funded startups can afford to use device fingerprinting in addition with auth tokens. This essentially involves keeping track of the last time you logged in, your IP address, your device characteristics then notifying if there is an unusual change in any of those metrics.

For instance, although I have never been to China, I once got a notification from Facebook that someone attempted a password reset on my account from China. This was shortly after the publication of LinkedIn's stolen database of users which affected millions of users including my account.

As someone unfamiliar with this, can you please elaborate? Would the host be fingerprinted on every subsequent usage of the authentication token, and using what methods?

On a basic level, you can include a IP or a country inside your authentication tokens. That's enough to block some unwanted access.

On a more advanced level, there is a two step process, you authenticate as usual with your password and get a token, then the site will authenticate your device.

The device fingerprinting is totally transparent, it saves and checks some characteristics from your computer, and ensure you come from the same device next time.

For instance, on Facebook you can see a list of known device somewhere. When you connect on a new computer it sends you an email "connected from a new computer is that you?".

Not the parent but I posted a plausible explanation to your question here: https://news.ycombinator.com/item?id=13731656

Good luck with that, people have been requesting for TOTP support on Namecheap for the past 3 years.

https://www.namecheap.com/support/knowledgebase/article.aspx...

https://blog.namecheap.com/two-factor-authentication/

Here's a list of alternatives someone asked a month ago:

https://news.ycombinator.com/item?id=13484739

Worth noting that authy is on the list. So if you synced your authy authenticators during that time, it's possible all your totp secrets leaked. One would hope authy encrypts those keys (I believe they do) client side, but yiiiiikes, I'm thinking about getting a yubikey.

Followup - authy's blog post confirmed what I thought: they do encryption of all the user-entered TOTP secrets on the client side and don't store decrypt keys. So anyone who was able to intercept your secret store would still have to decrypt it, which is (hopefully) Quite Difficult.

link: https://www.authy.com/blog/security-notice-authy-response-to...

Can you explain how 2FA would have helped?

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...

Reply on news.ycombinator.com