3

I am pretty new to cryptography and I have been studying up on TOTP (Time Based OTP) and while I have learnt how the computation works, I'm unable to figure out why using TOTP makes a system more secure.

Here's what I have understood. TOTP is used for 2FA, so the first factor would be your username and password. This as we know is not very secure in itself and hence we use the second factor, here the OTP.

So with TOTP, there is a secret key that both the server and the client have. So my question is that if an attacker has gained access to this secret, would he not be able to generate the OTP just as easily as the client software on my system because HOTP(key,counter) will remain the same for all? So to ensure TOTP is helpful, I have to make sure that the secret key with the client is safe? Let's say I'm making a software that is to be used by the public which uses TOTP based authentication. So will I be attaching a different secret to each of the clients and maintaining a database on the server end to match the secret server side?

If not, what's a safe way to have the same secret on both client and the server in this case?

mat
  • 2,558
  • 1
  • 14
  • 28
Arvind Sasikumar
  • 133
  • 4

3 Answers3

3

So my question is that if an attacker has gained access to this secret, would he not be able to generate the OTP just as easily as the client software on my system because HOTP(key,counter) will remain the same for all?

Yes, if an attacker learns your shared secret, he can calculate OTPs whenever she wants. But this is very unlikely, since every secret is unique (no reuse, like with a password) and never transmitted (apart from the initial agreement) a direct hack of the server or the client's token is the only possibility of obtaining it.

So to ensure TOTP is helpful, I have to make sure that the secret key with the client is safe?

Correct.

Let's say I'm making a software that is to be used by the public which uses TOTP based authentication. So will I be attaching a different secret to each of the clients and maintaining a database on the server end to match the secret server side?

Yes. Every user has a different key on your service. If you store it in a database or obtain via some deterministic calculation from a master secret is up to your implementation.

mat
  • 2,558
  • 1
  • 14
  • 28
0

Since you're already comparing a user's password to a (presumably hashed) value obtained from your app's database, you have a reasonably secure method for storing the secret server-side available to you.

You could store the OTP secret in your database in an encrypted form, using the user's password as part of the encryption secret, then decrypt the secret during the authentication flow to verify the OTP provided by the user.

One possible workflow would be to strengthen the user's password using something like PBKDF2, salt it, and encrypt with a cipher suite sufficiently secure for your use case (AES-256 is probably a good option for most use cases).

This would work for both HOTP and TOTP, and it'll protect you and your users from a simple database breach. Of course, you still need to observe standard security practices and the user still needs to do their part to ensure the security of their OTP secret and/or device.

Chris Cashwell
  • 101
  • 1
-1

OTPs need a shared secret key between client and server and if an intruder learn the secret key he can calculate the OTP in the same way clients do. So you need to keep the secret key secret.

Nevertheless there are still ways to give extra protection even in the case of the secret key were stolen. This could be done using what in the crypto community is called "obscurity" which means to hide the details of the algorithm used for the OTP. In this way, if an hacker enter to a web server and steal the table containing all the OTP's secret key for the client, he could not use it until he learn how the algorithm works.

Luis Orantes
  • 132
  • 6