10

Reading about TOTP-based authentication systems that use smartphones as one-time code generators, I seem to understand that typically the shared secret is generated automatically by the "server" (the system to which the user must authenticate), then encoded in Base32 or other encoding that results in "human readable" characters only, and then the user enters that secret in his/her smartphone app that will be used to generate the one-time codes. Often the server-generated secret is encoded into a QR code to be scanned with the phone to make it easier for the user to enter the secret into the app.

Assuming that it is true that the above is a typical configuration (which I'm not sure about), I am wondering what would be the disadvantages of making the user choose the shared secret and communicate it to the server to be stored, instead of the other way around.

That is, the user would create the shared secret and save it both into his/her smartphone app and into the server, and the server would use such secret as is (I mean without considering it as encoded). Or, the user would create the secret and encode it into Base32 before saving it into the server, and the server would consider it as encoded.

Since in my understanding none of these two cases is how a typical TOTP system works, I am sure that there are reasons why the user is not made choose the shared secret, and I would like to know them.

ADDED: I got quite a bit of info here that clarified a lot of my doubts. But I still have a doubt. As I understood, much of the point of two-factor authentication is to combine something you know (your regular password) and something you have (the code-generating device), but the device can be a common smartphone and it becomes the code-generating device only thanks to the user entering the secret into it (it doesn't matter how, QR code or keyboard or other, it's still a piece of info the user needs to know and that is all it takes). I wouldn't know what to reply to someone claiming "the secret is something you know or have just as much as the password is".

In other words, I do understand how the code-generating device that the bank gives to the user to login is something the user has and not something the user knows, and that's because that device had the secret set into it before being given to the user, so the user doesn't know the secret, so if the user successfully authenticates it means that it was actually the person who physically had the device. But if the device is a common smartphone instead, where the user itself is supposed to enter the secret (f.ex. via QR code) then a successful authentication only means that it was someone who knew the secret and had entered it into his/her smartphone.

Improve this question
1
  • 1
    There are some cases where this is used (for example, bluetooth), but it's mostly used for verification (that you're connecting to the correct device) and not authentication.
    – Qwerty01
    Jun 19, 2018 at 19:50

2 Answers 2

Reset to default
21

A better question would be: why would you do that?

When you develop an authentication protocol, you control all the variables. This means you can ensure, for instance, that the RNG you use is secure, that you're not reusing an existing secret and that you aren't picking a "weak" key. Plus, you don't have the problem of relying on a secure side channel for retrieving the secret from the user.

When you allow the user to generate their secrets, you throw all that away.

The only historical advantage of having users select their own secret is that they can commit them to their memory and not rely on (potentially insecure) local storage. In case of TOTP, you don't even have that advantage: your users needs to rely on some form of software to obtain the current code (which is the point of 2FA: force the user to have access to "something they have" in addition to "something they know").

So, yes, it's not too good an idea.

Improve this answer
14
  • Thanks, that clarifies things quite a bit for me. About why I would do that, I personally never would, because I know it's not done in reality and that must be for good reasons, so I wouldn't do it not even if I didn't understand such reasons (which I'm now understanding better). But the reason I heard for doing that was simply to make it "easier" for the user, who could then remember the secret because he/she had chosen it. And now I understand how that defeats to a good extent the purposes of TOTP in the first place.
    – SantiBailors
    Jun 19, 2018 at 15:30
  • 3
    But let me play devil's advocate, just to understand better. you don't have the problem of relying on a secure side channel for retrieving the secret from the user. However when the secret is generated by the server the user still needs a "secure side channel" for retrieving the secret from the server as well (be this the QR code or an internet connection), right? Actually, what are the most common wais to deliver the generated secret to the client?
    – SantiBailors
    Jun 19, 2018 at 15:31
  • @SantiBailors The point of Time-based OTP (TOTP) is that you don't need a secure channel--it generates keys either using time as a seed or by constantly generating keys with a delay (which is why some need to be re-synchronized after a certain amount of time). I believe you're thinking of HOTP, which creates a secure side channel with a separate device that only you have access to.
    – Qwerty01
    Jun 19, 2018 at 19:48
  • @Qwerty01 Actually I am thinking of TOTP, but I was talking about the shared secret it uses (together with the time-based seed), that the user needs to receive once (often in the form of a QR code) to set up his/her device.
    – SantiBailors
    Jun 20, 2018 at 5:10
  • 2
    @SantiBailors You do need a secure channel when you shared the secret, that is correct. It's easier to secure in that direction (server to device) because you can add any kind of protection between the two systems but it's not fundamentally different on that respect, you're right.
    – Stephane
    Jun 20, 2018 at 6:49
5

You should not do that. A TOTP is as secure as the key, and users are not a good source of randomness.

Add to this that most users will use their smartphones as the TOTP generator, and asking the user for entering a long, sufficient random string on the smartphone keyboard is asking too much. Now multiply by two: the user have to type the long, mixed case TOTP key on the smartphone AND your system.

It's not going to work. Better force the user to take a picture.

Improve this answer
4
  • Thanks, the advantages of generating the code that you mentioned make sense. But let me play devil's advocate, just to understand better. users are not a good source of randomness But does this mean that a TOTP secret is expected to be significantly less guessable than a password? Because passwords are normally allowed to be chosen by users, so someone who wants to persuade me to let the user choose the secret would reply something like "But you already let the user choose the password, which is as important, so why not the secret as well?". What would be a good comeback for such objection?
    – SantiBailors
    Jun 19, 2018 at 15:42
  • 2
    If you let the user choose the 2FA key, it's like asking him to put 2 passwords. Probably both the 2FA and the password are going to end up the same.
    – ThoriumBR
    Jun 19, 2018 at 16:16
  • 1
    @SantiBailors 2FA stands for 2 factor authentication. In this case, the password is the factor something they know, and the TOTP is the factor something they have. It would no longer be 2 factors if both the password and the secret were something they know, and having the user pick the secret doesn't contribute to proving something they have. But more importantly, it could make it easier for an attacker to guess what the user's secret is (20-30% are probably going to use "000-000")
    – Qwerty01
    Jun 19, 2018 at 19:58
  • @Qwerty01 We might be sitting on a misunderstanding where you are talking about the generated codes and I'm talking about the shared secret. Regardless, re something they know vs. something they have, that's where I'm stuck now, I just added this doubt in a comment to Stephane's answer and in the question.
    – SantiBailors
    Jun 20, 2018 at 7:53

You must log in to answer this question.

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