An application is logging wrong OTPs (but not correct OTPs). I asked the application developers to not log wrong OTPs because I do not see any benefits. However, they do not want to modify the application code, and are asking me (I have no access to source code) to prove that wrong OTPs in the logs presents security risks.

  • 7
    What security risks do you see? You don't mention that you see a security issue here.
    – schroeder
    Commented Apr 26 at 8:03

3 Answers 3


However, they do not want to modify the application code, and are asking me (I have no access to source code) to prove that wrong OTPs in the logs presents security risks.

If only OTP's are logged, there's no risk. OTPs are designed so that learning OTPs will not reveal anything about the shared secret.

The problem is if the user inputs wrong data, for instance passwords, into the OTP field, and that is logged. That may present a security problem.

  • 16
    +1 for passwords. And AFAIK logging the OTP code has no added value for debugging purposes (troubleshooting login issues), so it is the dev team that should justify why they're doing this in the first place.
    – Kate
    Commented Apr 26 at 13:29
  • 5
    While there may be security problems, there may also be customer support benefits. "It looks like you're putting your username into the OTP field." So the costs and benefits have to be weighed.
    – Barmar
    Commented Apr 26 at 15:30
  • 5
    If your logs are real-time enough that they do provide a customer support benefit, then they also present a security risk of an attacker somehow able to access these near real-time logs to bypass twofac. If the logs are delayed enough that they're not a security risk, then they also don't have customer support benefits. So I see no reason in logging these at all. If they're logged unintentionally, then the question of onus falls back on showing that there's a security reason that it must be scrubbed because now there's effort involved.
    – Cruncher
    Commented Apr 26 at 16:37
  • 4
    @Barmar The only way your particular example should happen is if insufficient validation is happening client-side (IOW, it should not be possible for users to type in characters that are not valid for the OTP in the OTP field) or the OTPs are rather non-standard (essentially all OTP systems these days other than Steam’s custom one use purely numeric OTPs). And if neither constraint is met, then there is exactly zero customer support benefit unless you are doing things you really should not be from a security perspective. Commented Apr 26 at 16:49
  • 2
    @AustinHemmelgarn proper client-side validation also kind of eliminates the part of the answer that mentions passwords accidentally input into this field. But I mean, the backend still probably shouldn't be logging it in case a client-side bug is shipped that breaks the validation.
    – Cruncher
    Commented Apr 26 at 16:58

As well as users accidentally logging passwords as @vidarlo mentioned, I can think of two other potential issues:

  • If a user mis-types their OTP, then what you're logging is a nearly correct OTP, with perhaps a single digit wrong or two digits transposed. If you have access to those, you could then try a series of variations that are much more likely to be correct than random guesses would (although only within a short window).
  • If you're using TOTP and the there's a time synchronisation issue on the user's device so that it's slightly ahead of your server, then you could end up logging a "wrong" OTP that will actually become valid a few seconds later.

Both are quite unlikely to be exploited, but given that there's very little (no?) benefit to logging incorrect OTPs, personally I'd want to stop doing that.

  • I agree with with the first point (and upvoted for it), but a time sync issue putting a user's device enough ahead for this scenario to occur seems vanishingly rare, to the point of being completely hypothetical IMO. If the user's device is ahead, it's probably very ahead and done intentionally for a game or something
    – Cruncher
    Commented Apr 26 at 17:01
  • 1
    @Cruncher to be honest, I don't think the first one is very likely either - it requires an attacker with real-time access to the logs, the username and password of the victim, the victim, to make a typo in their OTP and some luck in guessing the right permutation. They've both very much edge cases.
    – Gh0stFish
    Commented Apr 26 at 17:16
  • 2
    I've had systems lose their NTP connection and drift ahead by multiple minutes before I noticed. So it is a real thing, and not so "vanishingly rare" that it can be ignored. Commented Apr 27 at 6:45
  • @TobySpeight I have a Windows system that doesn't seem to sync with the NTP server automatically even when there is a connection. This has happened to me multiple times over the years I've owned various machines so it's probably not terribly uncommon. Troubleshooting that issue would be its own SE post but I do often find that my clock is about 10 seconds or so ahead which would indeed allow me to enter TOTP codes that only become valid in, say, 5 seconds or so.
    – Dev
    Commented Apr 28 at 6:25
  • Well, considering that sometimes hackers get in and take months if not years to expand their access and spy on stuff it might be that at some point a breach was there long enough to have access to real time logs. They can probably find the usernames by logs or other means. The password could end up getting logged sometime in the past as OTP, or maybe the user is reusing passwords from other applications that had breaches (happens all the time). Doing a typo on an OTP is not that rare. So, all in all, sure this is not a 10/10 vulnerability but it's a possible scenario.
    – Bakuriu
    Commented Apr 28 at 12:53
  1. Someone who obtained the logs can learn if a given OTP secret is the user's OTP secret by comparing the generated codes of the suspected secret with the logged codes. In case they do not know the password and the login page does not tell if the code is correct as long as the password is incorrect, it would give the attacker a way to check if they are using the right OTP secret without having the user's password.

  2. In the same way, an attacker could try to brute-force the user's secret (with the same odds they would have if they were monitoring OTP codes sent over the network) by generating keys until the generated codes match.

This does not mean these scenarios are large risks (as TOTP secrets are usually strong enough), but these are risks that would not exist without the codes in the logs.

If you like to assess these risks, one could say that the proof that someone is using a specific secret is only useful when one cannot access the login for the proof or does not want to access it (e.g. to avoid appearing in logfiles).

The brute-force attack still needs to brute-force all possible TOTP secrets, but without known TOTP codes one could not offline brute-force the secret at all.

An estimate of the strength of usual TOTP secrets from the comments:

RFC 4226 (HOTP), for example, suggests a length of at least 128 bits for the secret and recommends 160 bits. A brute-force attack against this would take billions of years -- potentially longer than the age of the universe (depending on what computing power you assume).

  • 1
    If they have the secret, then they can try it upon login. I'm not sure that the logs makes this a bigger problem. Brute forcing TOTP secrets is about the same difficulty as brute-forcing encryption keys. And again, the "known cypher text" in the logs doesn't reduce security, because you can just try them.
    – schroeder
    Commented Apr 27 at 16:34
  • @schroeder That's true. And I didn't say it is an effective attack, but answered the question what one can do with TOTP codes obtained from a logfile. It's an answer to the question what security risks there are, without saying that they are large risks. So I do not think there is a reason to downvote the answer, as it summarizes what the risks are.
    – allo
    Commented Apr 28 at 17:41
  • 2
    @allo: Your answer does not summarize what the risks are and is very misleading. Suggesting that the shared secret could be brute-forced is just absurd. RFC 4226 (HOTP), for example, suggests a length of at least 128 bits for the secret and recommends 160 bits. A brute-force attack against this would take billions of years -- potentially longer than the age of the universe (depending on what computing power you assume). This is not a risk in any way, not even by the most paranoid definition. vidarlo and Gh0stFish have pointed out actual risks, but this answer isn't helpful.
    – Ja1024
    Commented Apr 28 at 18:06
  • "indirectly learn about the user's OTP secret" -- no, and your example shows otherwise. You can't indirectly learn the secret but use the logs as a test. But like I said, so is the actual login process, so there is no risk here.
    – schroeder
    Commented Apr 28 at 22:13
  • It is not a feasible attack because it would take way too long. But it would be wrong to say that something is impossible just because it takes a long time. If you have a way to verify that a guessed secret is correct, you can brute-force the secret. You probably won't succeed, but that doesn't stop you from trying. By logging the codes, you create a way to verify a guessed secret, and that's the risk. It is not a big enough risk to worry about, but it would be wrong to say it isn't there.
    – allo
    Commented Apr 29 at 19:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .