1

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!

10
  • 2
    What problem are you solving with this? What is the advantage when compared to other systems, e.g. device specific key?
    – Josef
    Mar 31, 2020 at 14:22
  • @JosefsaysReinstateMonica I don't see this as a replacement for other systems. I see this as an augmentation. I used to work in credit card fraud detection, and fraud was often not detected until many transactions had taken place. In addition, we had no reliable way to determine which transactions were fraudulent. This system solves both problems. The drawback of a device specific key is that, if it is stolen, it is stolen forever. Neither the account holder nor the issuer have any way of detecting the theft. A mutating key will raise a flag as soon as both the thief and the user log in.
    – akovner
    Mar 31, 2020 at 14:40
  • This is fundamentally TOTP. If you concatenate it with the password, and extract it on server, you get the same functionality. No need to use anything fancy.
    – ThoriumBR
    Mar 31, 2020 at 20:34
  • @ThoriumBR This is not TOTP. The mutating key requires no intervention by the user. No need to look at a dongle or anything equivalent. In addition, there is no synchronization. The server has no idea what mutations the device will make. It works by detecting if there are two devices out there rather than one. It depends on the property that the mutating key has a traceable distance to a previous key. This is unlike cryptographic hashing, in which key distance is deliberately obscured.
    – akovner
    Mar 31, 2020 at 20:58
  • @ThoriumBR I think this points to a flaw in my headline. This system is not really authentication. It is fraud detection. It does not authenticate a user or a device. It tells the server if there are two separate devices out there that are trying to use the same mutating key. Why is this valuable? Because a fixed key can be stolen, and if it is, there is no reliable way to detect the theft. Even with TOTP systems, a malicious agent can (theoretically) steal the hash function being used on the clock, giving them freedom to use the credentials forever.
    – akovner
    Mar 31, 2020 at 21:04

1 Answer 1

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.

7
  • You are correct that the method is probabilistic, but that doesn't mean it won't work. Again, the issue is that is shows whether or not there was a branch in the key's use. This is similar to a "genetic distance". How do we know that polar bears diverged from brown bears about 500,000 years ago? Because we know that genes randomly drift apart at a certain rate once the populations diverge.
    – akovner
    Mar 31, 2020 at 21:47
  • I really wasn't asking whether or not this idea works. I have no doubt that it works; I am a mathematician and a data scientist, and I ran computer simulations of the idea when I worked in fraud detection. My question is whether or not something like this has been tried, and whether it is practical in the real world.
    – akovner
    Mar 31, 2020 at 21:48
  • Your point about the secure processor is well taken though. Perhaps this idea adds little value beyond it.
    – akovner
    Mar 31, 2020 at 22:09
  • @akovner, as ThoriumBR said, it might work but it's not worth it, because there are better solutions (either collect data about the session for probabilistic detection, or only use some kind of TOTP if you don't want any privacy issues)
    – reed
    Mar 31, 2020 at 22:11
  • @reed fair enough. I'm still on the lookout for some use cases, but I see that existing solutions cover much of the same ground.
    – akovner
    Mar 31, 2020 at 22:21

You must log in to answer this question.

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