0

Is there any major flaw in using TOTP in a way where the server sends its time to the client when the client requests to log in? The advantage of this is the client's time does not have to be set correctly, as it uses the time provided by the server. The disadvantage is the client must be online to generate the password, but in this case, since it's logging into a webservice, it has to be online anyway so this is not a disadvantage for me.

To elaborate my proposal:

         HTTPS                      JS fetch  
Server <-------> Client (browser) <----------> local python webservice

Dealing with a client logging into a webservice, via HTTPS. The client (browser) navigates to the login webpage. The server time is embedded in a JavaScript variable of the webpage. The client JS then calls a locally running python app that is a webservice, and passes it the server time. The locally running app has access to the secret key, and it uses its secret key along with the server time to generate the password, which it returns to the client browser, the client then posts the login credentials to the server.

run_the_race
  • 125
  • 5
  • "the client must be online to generate the password" -- is this a typo? How is generating a password a part of the process? How does the client's TOTP generator get the time as a separate token? Are you using a custom TOTP app? – schroeder Jun 02 '21 at 11:47
  • Often the device used to log into the service is different from the device used to generate the token. – CodesInChaos Jun 02 '21 at 12:03
  • @schroeder I added more information to make it clear. The local webservice would be using a python library for TOTP, so kind of yes a custom app. – run_the_race Jun 02 '21 at 13:11
  • @CodesInChaos In this case the device logging in is also the same device that generating the token. I dont see how would could separate them? – run_the_race Jun 02 '21 at 13:12
  • 1
    Don't use TOTP for this use case. That's a lot of extra overhead and the wrong tool for the job. What you've described is a good-old-fashioned challenge-response logic. Client and server share a secret key, Server sends client a temporary code, client encrypts the code with the shared key and sends it back. That way the client proves they know the secret. No time required, There are lots of CR models. – schroeder Jun 02 '21 at 13:15
  • 1
    If the server supplies the time, and the client trusts this, a malicious server could request not yet valid codes, which can be used at a later time by the attacker. In addition, I fail to see why you would want to use TOTP protocol in this scenario, as hilighted by @schroeder – vidarlo Jun 02 '21 at 14:27
  • You are not making use of one of the TOTP benefit if the device has to be online. Resync time in the background whenever the device is online. Time deviation more than 60 seconds takes long time and operating system often corrects it. – defalt Jun 02 '21 at 14:38
  • @schroeder, The description of " good-old-fashioned challenge-response logic" sounds exactly like TOTP, with but the "temporary code" is the time in this case. I looked at some challenge response libs (thanks for that, I did not know that concept existed), and its seems like there is an extra step in that the client must first send their username, before they get the nonce back. Then they calculate the response, and then send it back. Which is 2 x posts from the user. I guess extra security always equals extra work. – run_the_race Jun 04 '21 at 10:32
  • @vidario, I guess that is a real concern I had not thought of. I do think the risk is low given the URL is hardcoded into the terminal. So a hacker would have to be physically at the terminal and change the URL. – run_the_race Jun 04 '21 at 10:35

0 Answers0