RFC: Way to differentiate legitimate clients from illegitimate ones

[tyrannosaurus-becks]

This RFC is to discuss designing a feature that would differentiate legitimate clients from illegitimate ones.

Background

If a hacker were to get onto an Approzium client instance, they could potentially look around the instance and figure out from configuration files that an app is using Approzium. They would have access to the identity credentials in the enclosing environment, and therefore could put together a fully working script pulling a database challenge response from Approzium.

The only way to detect this attack would be using identity. If client applications were designed to only call Approzium once per the lifetime of an instance, then each instance's identity should only be seen once. Then, this attack could be noticed and alerted upon by seeing an instance identity used twice.

We would like to design a way to differentiate between legitimate callers and illegitimate callers so Approzium wouldn't respond to the hacker at all, and would immediately alert upon it.

Current Ideas

• A secret that only legitimate callers know, but the hacker does not know. If the hacker doesn't include it, the alert is triggered. This poses the problem of how does the client know the secret and how is it protected from the hacker?
• A client call count per instance, combined with a server-side call count per instance. If they don't tie out, alerting on the client and/or server side. This poses the problem of, what if an instance plans to run the Approzium client multiple times, or in parallel?

[tyrannosaurus-becks]

Here's another option to consider - sequential One-Time Passwords (OTPs). It would work like this:

• The person launching the application gains an OTP from Approzium.
• When it's used to establish a connection, the OTP is revoked.
• All OTPs can be configured to have a length of time to live - so if an application crashes (let's say because a memory dump has been performed by an attacker), they expire before they can be easily discovered and used. Memory dumps are typically huge and take a little bit of time to load and inspect on a separate computer, plus the time it takes to download the file.
• We could even consider encrypting the OTP in memory as a separate, follow-on feature.
• Optionally, Approzium can be configured to respond with a new OTP whenever one is used.
• Since all responses are encrypted, the original OTP may live on a file but be dead rather quickly, and all further OTPs live in memory.