0
$\begingroup$

In my application, the user logs in when connected to the central database, and their login credentials are authenticated against that data and cached (encrypted). Then, when the user is offline, their credentials are authenticated against that cache. So far so good.

But sometimes, the user MUST use the application when offline AND the data cache is corrupted, so they can't get log in. There is no possibility of accessing the internet, even via mobile phone hotspot, but it is still mission critical to be able to run the application, and there is no time to go somewhere and try to find an internet connection.

So I have been tasked to implement an offline login method so that the user can call tech support from a landline at the facility and verbally receive a code that they can enter and the software will recognize this and treat it as a valid authentication. Because the transfer is via human voice, this code has to be reasonably short and human comprehensible (i.e. not a 100 character base64 encoded string).

The code must embed at least a user id (integer) and expiration date (could also be just an integer, like the number of days since 1/1/2022) and will only be given to the same person once on the same day, so the current date could function as a one time pad.

Also, it doesn't need to be massively secure, just enough to prevent someone guessing tomorrow's code by trial and error. (They have the installed application binary, so with sufficient skills, they could just debug it and bypass the authentication code altogether; I'm not trying to keep out the NSA, just the "ordinary" troublemaker.)

How might this be done?

Improve this question
$\endgroup$
6
  • 1
    $\begingroup$ 'the user can call tech support from a landline at the facility and verbally receive a code" seems highly insecure. Have you considered using (hardware-) tokens, that provide a phrase for log-in? $\endgroup$
    – Fleeep
    Commented Dec 16, 2021 at 15:17
  • $\begingroup$ Why insecure? Someone could eavesdrop on the call, but I'm not worried about someone getting a code that only works for one day. And I'm not worried about impersonation either. $\endgroup$
    – Joshua Frank
    Commented Dec 16, 2021 at 16:48
  • 1
    $\begingroup$ if you are not worried about impersonation, then why does the User need to log-in? And, can you please specify what you mean by "the data cache is corrupted". Since the code that was received through the phone call would also have to be validated somehow (i.e. against some information saved in the App). If the App does not have any (persistent) cache, then you are left with "hard coded" data in the App, that cannot change for different users. $\endgroup$
    – Fleeep
    Commented Dec 16, 2021 at 17:21
  • $\begingroup$ The cache is a file, but sometimes in the field this file is corrupted or deleted by user error, which is on them. But still we need to get the app running or we look bad as a company. The app still has its algorithms, though--unless they delete or corrupt the executable, and then of course we're screwed--and that algorithm can run and verify that a code is the valid "back door code" for today. $\endgroup$
    – Joshua Frank
    Commented Dec 16, 2021 at 17:25
  • $\begingroup$ By impersonation, I meant an non-authorized user pretending to be someone else and calling up and asking for the back door code, or someone intercepting the call and pretending to be tech support. The users and tech support are known to each other and we'll assume that simply recognizing each other by voice is sufficient security here. $\endgroup$
    – Joshua Frank
    Commented Dec 16, 2021 at 17:28

2 Answers 2

Reset to default
2
$\begingroup$

No, without a (local) "data cache" the "tech support" provided code cannot depend on "at least a user id (integer) and expiration date".

In more detail: The question asks for a (one-time) authentication, where

  1. the input can be easily provided by a human, through an authenticated channel (which is also not subject to eavesdropping).
  2. the application has no persistent/ user-specific storage.

The main issue that I see is that "the data cache is corrupted": In order to verify an input, an algorithm would have to compare the result against another input.

For example, consider an oversimplified hash-based log-in procedure: The user provides a password. An algorithm takes as input the password, along with a string provided by a data cache; computes the hash of the password and compares it to the string.

If there is no data cache, then the algorithm can only use hard coded values, i.e. values that were shipped with the application and do not depend on user input.

Comments: "so the current date could function as a one time pad."

Note that for a one-time pad to be perfectly secure the key has to be random. This does not add any security.

Out of scope since this is not considered secure, or with in the scope of the OPs question:

If you would want a hard coded value for a specific day, the simplest way for this would be to hard code images of a one-way function (instantiated by a cryptographic hash function) into the application. Then the tech support could provide a human readable passphrase (Cf. Stackexchange: Long Dictionary Passphrase, Stackexchange: Why use random chars in pw? ), where the tech support has a "valid passphrase" for each day. The passphrase can be provided as an input by the user; the image of which would be compared to the hard coded values assocaited to that day. However, this is not secure for several reasons:

(1) The hard coded values

  • would be the same for all users, e.g. cannot contain the user-id
  • once a passphrase is leaked, anyone with can access the app

(2) The date does not really add security, except that the adversary would have to know that different days have different passphrases.

So I would strongly recommend against this.

Improve this answer
$\endgroup$
0
$\begingroup$

In the end, I didn't solve this with symmetric encryption, but simply created a hash on the server and a hash on the client, and compare them. The hash is just a 32 bit int, so it's easy enough to read over the phone. I use a key and the date in the hash, so it's different every day.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.