Hacker News Reader

Comment by tialaramex | Hacker News Reader

The counter feature is dubious. You correctly describe the upside - if Bob's device says 4, then 26, then 49 it's weird if the next number is 17, and we may suspect it's a clone.

But there are many downsides, including:

Devices now need state, pushing up the base price. We want these things to be cheap enough to give away.

The counter make tokens weakly trackable. If Facebook knows your token's counter was 205 when you signed in at work this morning and 217 when you signed in from your iMac this evening, somebody who visited GitHub at midday with counter 213 might be you, someone with counter 487 definitely isn't you, or at least not with the same token.

View on HN

> Devices now need state, pushing up the base price. We want these things to be cheap enough to give away.

State is only expensive when it adds a significant amount of die area or forces you to add additional ICs. If you need a ton of flash memory, you can't put it on the same die because the process is different, and adding a second IC bumps up the cost. However, staying with the same process you used for your microcontroller, you can add some flash with much worse performance... which is a viable alternative if you only need a handful of bits. Your flash is slower and needs more die area, but it's good enough.

> The counter make tokens weakly trackable. If Facebook knows your token's counter was 205 when you signed in at work this morning and 217 when you signed in from your iMac this evening, somebody who visited GitHub at midday with counter 213 might be you, someone with counter 487 definitely isn't you, or at least not with the same token.

What kind of ridiculous threat model is this? "Alice logs into Facebook and GitHub, and Bob, who has compromised both Facebook and GitHub's authentication services..." Even then, it's not guaranteed, because the device might be using a different counter for Facebook and GitHub.

> the device might be using a different counter for Facebook and GitHub.

At least for YubiKey, it appears to use a global counter:

https://developers.yubico.com/U2F/Protocol_details/Key_gener...

> There is a global use counter which gets incremented upon each authentication, and this is the only state of the YubiKey that gets modified in this step. This counter is shared between credentials.

Having a global counter does seem like it could weaken the ability to detect cloned keys. If an attacker could clone the key and know the usage pattern (e.g., there are usually 100 uses of non-Facebook services between uses of the Facebook service), then they might be able to use it for a while without being detected. Though, having service-specific counters may have worse security ramifications (e.g., storing which services the key has been used with).

Though if an attacker is going to that much trouble, they may as well just use the wrench-to-the-head method.

The main benefit is that the number should always be increasing. The moment either key uses an old number, the service knows the security device was cloned. The attacker will have to be sure not to increment it more than the target or else an attempt by the target would notify of the cloned key.

Keep in mind that "Bob" in this threat model is Facebook (because they are one of the entities that tries to track what everyone is doing everywhere). So it only needs to get the Github nonce. Collusion on the part of Github is, I suspect, much more likely than Facebook compromising Github's login flow.

Maybe sites colluding with their ad providers to track people is not part of your threat model, but it definitely is for some people. Yes, I know Github does not host ads, so isn't a good example of this threat model.

U2F tokens are already cheap enough to give away. We carry them around in sacks and hand them out at events.

they are not that cheap.

the only yubikey that works with mobiles (NFC) is $50. the cheapest u2f I could find (it only has usb-a port) is $20.

There are at least two U2F keys I was able to find on Amazon which were under $10 USD:

https://www.amazon.com/dp/B01N6XNC01 https://www.amazon.com/dp/B01L9DUPK6

The latter is an open source / open hardware design:

https://github.com/conorpp/u2f-zero

Neither of them works with smartphone hence not of practical use.

I think you might be having trouble with the concept of a U2F token. The mail application on your phone doesn't need a token; it already has a long-term cryptographic binding to the server.

> Devices now need state, pushing up the base price.

You can buy pretty decent (16Mhz, 2K EEPROM, 8K flash) microcontrollers for less than twenty cents (my numbers are from 7 years ago, things are probably cheaper, faster and bigger now). A few bytes of stable storage -- whatever you need to safely increment a counter and not lose state to power glitches -- are not going to add significantly to the cost of a hardware token.

I can think of a few ways to reduce that tracking risk. The token could use a per-site offset (securely derived from the per-site key) added to the global counter, and/or could have a set of global counters (using a secure hash of the per-site key to select one). I don't know how much that would increase the cost, or if there's something on the standard mandating a single global counter.

Nothing mandates it. In fact, it's specifically discouraged in the WebAuthn spec:

> Authenticators may implement a global signature counter, i.e., on a per-authenticator basis, but this is less privacy-friendly for users.

Since you can have multiple keys on the same site, you could go one better, and have a per-key offset. When the key is rederived from the one-time nonce sent from the server, you'd also derive a 16-bit number to add to the 32-bit global counter. But even that wouldn't actually be enough to make correlating them impossible.

A large but finite set of independent global counters is a great idea, though. 256 32-bit integers is just 1 KiB of storage.

Reply on news.ycombinator.com