A proposal for effortless two-factor authentication

Question

I have an idea for device-level two-factor authentication that involves no direct input from the user, and I wanted to find out if something like it has been tried before.

Let's say I have an account that I access from my cellphone (or any device). When I send the password, the device will automatically add its own "password", which you can think of as a binary string. But here's the key: the device password will randomly mutate at a fixed rate.

For example, on the day I create a new account, the device will automatically initiate its password to the all 1 vector: 1 1 1 1 1 1 1 1. But when I log in a week later, there is some probability (proportional to the time interval) that each of the entries has changed. Thus the new device password might be 1 1 0 1 1 1 1 0. Two of the bits have decayed. The calculation of the random decay is entirely local to the device.

How is this a form of two-factor authentication? Now let's suppose that a malicious agent tries to log in on a separate device. What device-level password do they use? They can't use the original all 1 vector, because that will give them away. They know the rate of random decay of the password, but the exact bits that are changed is hidden from them. Say they submit 1 0 1 1 0 1 1 1, trying to guess which bits have decayed. The server looks at this password, compares it to the previous password 1 1 0 1 1 1 1 0, and sees that it is impossible for this new password to be valid.

Clearly a much longer key is required, and there are more complicated randomization schemes than just starting from all 1s and decaying randomly. But the idea has a number of advantages:

1. Effortless to the end user.
2. Does not invade privacy. Currently, many systems use a "fingerprint" of a person's cell phone, which is information gleaned from any available information on the phone. In addition, a random key is more reliable than a fingerprint.
3. The decay rate actually provides some traceability, telling authorities when a device was compromised. Imagine a credit card issuer looking at fraudulent charges. If the random passwords diverge by a lot, then the device was compromised a long time ago, otherwise the compromise was recent.

There are some disadvantages as well:

1. The process does not identify the true account holder. It only raises a flag that there is a malicious agent out there, without alerting anyone as to which is which. Perhaps once such a detection is made, a third authentication factor can be used.
2. The process is probabilistic. There is no certainty of flagging a malicious agent, only a probability. With proper design, this probability can be made very high.

Essentially, this scheme makes the value of stolen credentials decay very quickly. Let's say a criminal steals your passwords, both the human password, and the device level password. The criminal must use these credentials before you do to get any value from the theft. If you log on first, you send your mutated device password along with your human password, and the thief's stolen credentials are now useless. Even if the thief uses the credentials before you, when you log in next, that will flag the system that there is a problem. The thief's gains are thus significantly limited.

My question is, does anything like this exist? Do you think this is feasible? practical?

Thanks for your input!

Answer 1

No, it won't work. Because of one key factor: probability.

If you throw probability into any system, there's no guarantee that the other side is real, or not. Like you cannot say with certainty that a dice is fair or not by throwing it a few times. You can say that probably the dice is fair after lots of throws. You only have a probability, as you already stated.

Look at the server. It receives a key 0 0 0 0 0 0 0 0. It should not have decayed so fast, right? But every bit have a probability for decaying, not a fixed rate, so it's entirely possible that every single one decayed at the same time. Why not? So how can the server tell that the device was compromised?

If you are willing to go for the probability instead of certainty, you can train a model with all requests for the user: duration, time of the day, type of purchase (in case of a credit card), and block when a sizable change occurs. Credit cards already do that, and that usually works well.

A fixed device key is better than a randomly mutating one. Storing a device key on the Secure Enclave on iPhones or the equivalent on Androids makes the key very difficult to steal (think State-level difficulty). When the application is first installed and the user authenticates itself, generate a token server-side and store it safely on the device. It will be used to generate TOTP tokens and add it with the next authentications automatically, without user intervention.

It basically have the same upsides from your idea: no user interaction needed, it does not fingerprint the phone or invade privacy. Other than that, it is not probabilistic, and identify the true account holder. An attacker would have to steal the device, as extracting the keys from the Secure Processor is very difficult, and maybe cost more than any financial gain it would bring.