← Back to context

Comment by dogacel

5 days ago

Good catch. In my mind storing that random number is similar to storing a plain-text password, thus I thought they were generating TOTPs. Let's hear from others how they implemented it.

13 comments

dogacel

Reply
crdrost  5 days ago

So you are right that the random number becomes "password-like", but of course if you really care about that you don't need to store the exact random number, just as you don't have to store a raw password.

However, if your random login code is easily typable then it's usually drawn from a small enough keyspace that any such code is trivially brute-forceable. Like if it's decimal digits you need more than ten.

So in practice people just trust that you are on good terms with your email provider and anyone else with access to your email, and use other mechanisms to limit access to these codes from insiders.

lucb1e  5 days ago

What's the difference between storing a random number and storing the OTP secret? It's all ones and zeroes in a database

If you store the OTP secret in an HSM, then you can do the same when generating a random number. I'm not aware of anyone actually doing that though (I surely won't have seen even 1% of what's out there, but as a security consultant I get around at least a little bit)

SoftTalker  5 days ago

It would be, but you could still store an expiration time, and limit the number of attempts to use the code. Considering you're probably sending it to the user insecurely anyway (via email or text message), that's probably safe enough.

  • lucb1e  5 days ago

    > > storing that random number is similar to storing a plain-text password

    > you could still store an expiration time, and limit the number of attempts to use the code

    Storing plain-text passwords is bad because:

    1. Users re-use passwords

    2. An attacker can read the access token from the database (as with SQL injection) or capture it in transit (as on insecure connections) and log in directly (if that is still useful when having, e.g., SQL-injection-based database access)

    I do not understand what threat limiting the number of attempts protects against. Even if you have that limit implemented on a hardware level, the attacker either knows the right code or can crack the hash if it's a hash of just a few digits. With something like PAKE you can protect against capturing in transit but on secure channels (e.g., if you already use TLS) that's typically overkill

    (Of course, you absolutely need to have rate limiting on OTPs, but that is not to protect against the correct code being read straight from disk by the attacker; it's to protect from guessing the digits, a surprisingly common flaw)

    > you're probably sending it to the user insecurely anyway (via email or text message)

    (I kind of want to remark about this assumed insecurity: the user needs to be targeted for these to not be adequate. Attackers very rarely go after people to the point where they first compromise an email inbox and then look for your specific service, or drive up to the person with cell tower spoofing equipment. It surely happens in red teaming exercises, spy scenarios, if you have a stalker, and probably more, but it's not the common case. Anyway...)

    I don't see how rate limiting and expiration helps against sending it via moderately-secure media either. This is necessarily plain text for random codes because the user would otherwise need a decryption key and then you're basically back at the TOTP scenario makes a difference for at-rest storage security. So with them being plain text, if someone is intercepting your SMSes or sitting in your inbox, they'll either manually trigger the code sending or wait for the legitimate user to do this and then log in. Similar to the previous bit: sure, the security of the transport method is relevant, but not for the security of token storage on the server

  • dogacel  5 days ago

    Thanks for all your insights, I have updated the post to outline this as a "theoretical" use-case rather than a practical one. I also revised it to include random number approach.

    • notpushkin  5 days ago

      Perhaps you could also highlight how in usual TOTP implementations (“scan this code with your authenticator app”) there’s no channel to MITM? I think it’s one of the key pros of TOTP vs, say, SMS as a second factor.

      2 replies →

inferiorhuman  5 days ago

I have to pull a number from Google Authenticator to log into my FB account so I can only assume they're not simply generating random numbers.

  • dogacel  5 days ago

    Two different flows, an online and an offline.

    TOTP devices can be powered offline, which makes it extra secure, as you don't transfer any data around, possibility of leaking it is extremely low.

    Random numbers could only work in online flow, where server sends you a one-time code using a secure communication method, such as a trusted phone number or email address.