1. 18

  2. 12

    I can’t tell if this detail got dropped because it’s peripheral to the article or because the author was unaware of it, but here’s my nit to pick:

    This all sounds complex but the algorithm is very simple:

    hmac = SHA1(secret, SHA1(secret + input))

    The omits the role played by the inner and outer padding:

    hmac(secret, input) = SHA1((secret xor 0x5C) || SHA1((secret xor 0x36) || input))

    The HMAC security proofs require that the inner and outer keys (i.e., secret xor 0x36 and secret xor 0x5c) are different. Those values were chosen to ensure a large Hamming distance.

    1. 2

      I actually did leave that out on purpose - but I will mention my description of the algorithm is high level, thanks!

    2. 2

      “Using the current time (as with TOTP) is less predictable and thus more secure.” – I don’t think that the author thought very hard about that sentence as he wrote it.

      Especially since he just got through talking about how the server predicts a range of likely values, to account for time taken to enter the token (and for clock drift). If I want to predict the next input, I can just glance at a clock.

      Non-time HOTP has a less predictable input, unless you can count every request made by the client. The biggest problem with HOTP is that because the client and the server need to remain in sync as they increment the counter, you can’t use multiple token devices and thus the client device becomes a single point of failure. By contrast, with TOTP you can record the secret (in a PGP-encrypted file or equivalent), load an authenticator app, load two if you are paranoid about N+1 in devices you carry with you, and be able to recover without external intervention if your phone breaks: use qrencode(1) to generate a new QR barcode to scan into the new phone.

      1. 3

        Yeah I agree this was not my finest moment, I guess what I meant with that is that with TOTP the active token changes every X amount of time while with HOTP the token potentially rotates a lot less often. So more susceptible to brute force.

        UPDATE: I’ve removed the sentence entirely as it is not relevant to the article anyway.

      2. 2

        You’re really going to want to rate limit guesses if you do this. A search space of one million is nothing, even for an online attack.

        1. 1

          TOTP is well documented elsewhere, but the real missing magic with authenticator is how to read QR codes. I made a short attempt to create a command-line authenticator and had TOTP working, but getting it to read a code would have been a guessing game based on my searching.

          Anyone have ideas or recommendations on how to implement a QR reader in a language that doesn’t have libraries for solving the problem?