2

As we all know, nonce is needed to prevent replay attacks. Everywhere I read about nonce, I see that client always fetches one from the server, and, to improve security even more, it also can add its own client nonce (cnonce).

Just like on this diagram:

enter image description here

This scheme adds an overhead of one more roundtrip to the server; and I'm trying to figure which attack vectors will become possible if we only use client nonce, and ensure on the server that cnonces are never reused (to avoid storing all used cnonces, obviously we could just require that every next cnonce for a given API key is larger than the previous one, and only store the last cnonce for the given API key).

So far I fail to find any new attack vector: by ensuring that cnonces can never be reused for each API key, we eliminate replay attacks completely. Am I missing something?

Dmitry Frank
  • 195
  • 11

1 Answers1

3

Replay attack becomes possible. Because an attacker can choose his client nonce, he can just choose a nonce that a legitimate user picked and replay his login.

Note that technically you can get rid of the additional round-trip by choosing a predictable nonce as server nonce, such as the current time + user name. Then you store the last used time by user and only accept nonces with higher time to prevent replay. While this is not as secure as an random nonce, it may be enough for some use-cases.

Namely with this approach, you may have to implement a grace period for clocks, that are not precise, accepting nonces which are off by some time. An attacker may be able to obtain a token and use it within this time period, where he would not be able to use it directly, though this is quite unlikely. An attacker may also be able to get tokens for future if he can manipulate the clients clock. And possibly other vectors may be opened by using this approach.

Peter Harmann
  • 7,728
  • 5
  • 20
  • 28
  • Confused by "choose a nonce that a legitimate user picked and replay his login". Once a legitimate user has logged in, server has remembered that this particular cnonce is used (in fact, just incremented a counter, so that only cnonces which are larger could possibly work from now on), and replay just won't work. – Dmitry Frank May 18 '18 at 22:44
  • @DmitryFrank but that would be a server nonce, as lets say if you want to log in from different computer, you can't know where your counter is at without asking the server. Client nonce is chosen entirely by client, while server nonce can be what you described. – Peter Harmann May 18 '18 at 22:48
  • Yeah for a different computer a user is supposed to create a separate key pair (API key + Secret key), and since those counters are kept on server on a per-key-pair basis, each device can use its key pair and its cnonce. However, I didn't think that it's a server nonce; I was assuming it should be opaque for the clients. Thanks for clarifying. – Dmitry Frank May 18 '18 at 22:50
  • 2
    @DmitryFrank As long as server checks it, it is not really a client nonce, it is sort of a predictable nonce like I described or something similar. A pure client nonce would be chosen by the client and not validated by the server in any way. It is either a server nonce or some hybrid in between. – Peter Harmann May 18 '18 at 22:53