@adamshostack FWIW, on the "using intercepted TOTPs to 'crack' the seed" side, I consulted with @lakiw and a few others, and the consensus is that the important thing is intercepting a couple of the TOTP codes, and the length has little impact on effectiveness of the associated attacks on deriving a seed. But this was an informal survey, and I don't know of any public/formal research to point to.

To be clear, this is a separate concern from the "can someone guess the TOTP itself externally" concern.

@tychotithonus @adamshostack Not directly answering your question as I'm talking about standards vs. "security benefits", but the current NIST 800-63b states that for out of band verifiers: "The verifier SHALL generate random authentication secrets with at least 20 bits of entropy" [page 18] which is **squints** just a bit more than 6 digits. In the updated 800-63 draft they revised this to "the authenticator MAY truncate its output to as few as six decimal digits or equivalent".

Once again, no security justification but if you want to deal with regulations you really should have at least 6 digits (vs. 4). As to forcing a longer TOTP I'm not aware of any regulation or standard that requires a longer TOTP. The one minor exception is that in NIST 800-63b it seems to imply that if your TOTP secret has greater than 64 bits of entropy then you don't need to apply rate limiting on guesses to it, (there's some contradictory statements elsewhere so not totally clear-cut on this lack of requirement). But from a design standpoint if you don't want to implement rate-limiting for "waves hands" some reason, a case could be made to have 64 bit equivalent TOTP. I don't see similar wording in the new draft standard but would need to dive into that some more to understand what its view is on this.

@tychotithonus @adamshostack

Warning this is another side tangent that doesn't actually show any risks to only having a 6 digit OTP but I figure it might help to give some background on the discussion @tychotithonus and I were having.

I was worried at one point that shorter OTP tokens could cause problems for attackers trying to clone the underlying token. The scenario is where an attacker has stolen all of the OTP seeds, but needs to match up a particular seed with data obtained via a keystroke logger to clone a particular token. [Attack Reference: The RSA hack https://www.wired.com/story/the-full-story-of-the-stunning-rsa-hack-can-finally-be-told/]

Part of the challenge for an attacker here is false positives from shorter tokens. I looked into this back in the day for the RSA hack and created a PoC tool called eRSAtz to help in this attack scenario, (never released it since I don't want to get sued). A couple of high level findings from that research:

1) There are actually a bunch of different RSA securID backend algorithms. The ones used during the time of the attack were updated from the original flawed implementation. There was actually a different algorithm for the digital-only tokens that focused a lot on making it so you couldn't just create your own fake seeds. For my research I used the SecurID version found in the Cain and Abel SecurID module.

2) Part of the "secret" was actually a serial number that isn't secret. These serial numbers are assigned to companies (and in fact were printed on the OUTSIDE of securID shipping boxes to make managing them in the warehouse easier). What this means is that an attacker in possession of all the seeds doesn't need to worry about collisions from serial numbers assigned to other companies they aren't targeting. This reduces the number of false positives dramatically

3) Simply collecting two TOTP entries from your keystroke logger pretty much negates any issue with collisions.

4) This is a side tangent to a side tangent, but I have to say I was really impressed by the design of SecurID. There are a lot of design decisions that sound bad when talked about out of context, (see my comment above about printing serial numbers on the outside of shipping boxes), but when you look at the overall design doesn't cause any real weaknesses and makes the system much more usable. It's a really well designed algorithm, assuming of course that all of your seeds don't get stolen.