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.

SantiBailors
  • 391
  • 2
  • 11
  • 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 '18 at 19:50

2 Answers2

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.

Stephane
  • 18,557
  • 3
  • 61
  • 70
  • 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 '18 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 '18 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 '18 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 '18 at 05:10
  • @SantiBailors The whole point of TOTP is to allow for the creation of a cheap 2FA, not to replace passwords. Having the user remember the secret defeats the point. – Stephane Jun 20 '18 at 06:46
  • 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 '18 at 06:49
  • @SantiBailors The point of TOTP is NOT to get rid of the secure channel: you still need it because TOTP is usually far from enough to secure the authentication by itself (the token is too short for that). It's a mean to create an additional layer of protection on top of another authentication mechanism (usually password-based but it can be something else) – Stephane Jun 20 '18 at 06:51
  • _The point of TOTP is NOT to get rid of the secure channel_ Sure, I wasn't suggesting that that was a point of TOTP, I only asked about the secure channel to understand the difference between such channel in the two directions (server to device and viceversa), and your explanation about that makes a lot of sense for me (it's easier to secure in one direction than in the other). – SantiBailors Jun 20 '18 at 06:58
  • _The whole point of TOTP is to allow for the creation of a cheap 2FA, not to replace passwords._ This is the part where my brain is still stuck. I wouldn't know what to reply to "the secret is something you _know_ or _have_ just as much as the password is". I'm not advocating choosing the secret, I'd never do that because I'm no expert so the fact that I don't fully understand is irrelevant and I'm going with the experts' consensus since there is one, I'm just trying to be logical to the bone because I might have to defend from this proposal by people very good at never admitting being wrong. – SantiBailors Jun 20 '18 at 07:28
  • @Stephane security is dependent on cost and risk. TOTP is usually more than enough for most authentication needs, but it is insufficient alone for 2FA. A 6 digit password changing every 30 seconds would be extremely difficult to bruteforce if the server limits the number of tries against it. – Qwerty01 Jun 20 '18 at 18:04
  • @SantiBailors The shared secret shouldn't be something the user knows, otherwise it would be something they know and not something they have. Think of it this way--if an adversary locked a user in a room until they shared every secret they knew, the adversary would still be unable to authenticate because they need something the user doesn't know--the TOTP token. – Qwerty01 Jun 20 '18 at 18:05
  • @Qwerty01 But your example assumes that the user is memorizing his/her passwords, which is often not the case. Otherwise, that adversary would need to demand the user to retrieve his/her notes or password manager or whatever means the user uses to store his/her passwords, in which case why not demanding also the QR code or whatever other means through which the user had the secret delivered? – SantiBailors Jun 20 '18 at 19:17
  • @SantiBailors I think you're taking it a bit too literally. I'm trying to illustrate why a password is something you know and a TOTP token is something you have, and a situation for why having both may be important. How each is implemented is up to the needs of the application. – Qwerty01 Jun 20 '18 at 19:51
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/79168/discussion-between-qwerty01-and-santibailors). – Qwerty01 Jun 20 '18 at 20:01
4

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.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • 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 '18 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 '18 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 '18 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 '18 at 07:53