Do keystroke dynamics always generate one profile per person?

Question

An associate of mine has asked my help because he is being fined $1000 because a web application he uses in his line of work claims he's shared his logon credentials with someone else, violating their terms of service. He claims he's not done this.

The site claims they know there are multiple humans using his password because they use keystroke dynamics during the logon process. To quote their auditor:

"The main factor on your account is multiple typing patterns, which indicate multiple users."

The auditor provided an audit of login events which I've reviewed. It shows 5 unique "keystroke IDs". They only track successful logons and use of the Backspace key clears the entire password forcing re-entry from scratch. I believe they use a browser plug-in to capture the data.

What doesn't make sense is that all of the logons came from my associate's laptop from only two public IP addresses: his office and his home. Of the 5 keystroke IDs, 4 happened at work. Interestingly, 4 of the 5 patterns were also present in logons made from his home.

I think these patterns are all being generated by my associate, but I'm not familiar with keystroke dynamics enough to explain how it could generate false-positive results.

Is it true that multiple typing patterns indicate multiple users? If not, what could explain one person having multiple patterns?

Answer 1

A common theme with biometric authenticators is that they are based on bodily features or behaviors which have inherent variability. Most authentication systems do a couple of things to reduce the rejection of valid users.

First, these systems allow a defined amount of variability when comparing biometric samples. In other words, they acknowledge that you won't type your password exactly the same way every time (in fact some systems look at exact matches as an indicator of a replay attack). There is usually a threshold within the system to still allow authentication if the supplied biometric sample is 'close enough'. Make the system less forgiving and you increase your False Rejection Rate (FRR), which means legitimate users aren't authenticated. In this case the FRR may actually indicate that the user was successfully authenticated but a new 'keystroke ID' was generated. Make the system more forgiving and you increase your False Acceptance Rate (FAR), which means unauthorized users are more likely to be misidentified.

Sometimes this control can be adjusted by the system administrators to meet their unique deployment needs, and other times the vendor/developer hardcodes in a value that they feel works best for most users.

Second, these systems need to capture a sufficient number of samples from the authorized user in order to create an accurate biometric template. This is more important for a biometric like keystroke dynamics where your typing will change from entry to entry. The more samples this template is based on the better it works with the first control that compares whether new authentications are within the margin of error of the authorized user template.

What we don't know, and may not be able to find out, is how these two elements are handled by the service your friend uses. It's possible they tuned their system to reduce the FAR so much that variations in how he types during subsequent logins are generating different 'keystroke IDs', despite it really being him. This research paper on keystroke dynamics lists their FRR at around 5%. In the context of this service that might mean a similar FRR would generate a different keystroke ID for your friend's valid logins in 1 out of every 20 logins.

We also don't know how many logins they used to train their system for his valid biometric template. They may have just used his initial password entry during account setup. Or they may have trained the system using a few dozen of his logins before looking for unauthorized use. Clearly the second approach is the one they should have used in order to improve the quality of their biometric template.

Unless this is a new system or a shady vendor, I would assume that they'd have already fixed these problems since they would presumably affect all of their customers and cause a lot of complaints. But it's also possible that you friend just has more variation in his password entry technique than normal users.

I agree with Johnny's answer that having different keystroke ID profiles is just one indicator that the vendor should use to determine if fraud is occurring. Without details on their particular biometric system it is possible that he is solely responsible for all of these logins and is mistakenly being accused of violating the ToS. He should ask them for more information beyond just the source IP and keystroke ID of the logins, or make the argument that the evidence they've supplied so far is flimsy.

Answer 2

Multiple typing patterns does imply multiple users, but it is one metric of many that an analyst is supposed to review before making an accusation that credential sharing is going on. They should be cross-referencing with IP or other user/behavioral analytics (times/date of access, patterns of behavior, simultaneous logins, etc.). before making such an accusation. This is insanely sloppy.

I have a good idea of what line of work your associate is in since we deal with this problem ourselves but have not found an adequate solution to date. He will likely have a tough time fighting this (because of the nature of contracts he signed), but he really needs to complain until he's out of breath. A keystroke profile violation is not conclusive evidence of contract breach.

Answer 3

I doubt that any behavior based on password typing biometrics has enough precision to make such a determination

I work with artificial intelligence to process activity logs and predict failures. I have amazing success on its applications, but is far, far from 100% precision on its predictions.

I did not attempted to use artificial intelligence to keystroke detections, but I imagine very well how it is done. First, we have to understand where the data come from: what is the input? As far as I know, keyboards allow us to know which key is pressed. Only one at time, except for the shift/caps/control/alt/scroll keys. That mean that such a model will have to work with the timings for the keyup keydown events for each char typed, as well the combinations of shift keys. There no more data beyond that.

The model will develop a complex mathematics behind it to combine those inputs in profiles.

On my intuition there is too little information to allow a good match. Passwords are too short and too rendom to determine precise patterns on my view. If we was talking of a bigger sample size, like the usage within the application I may be more prone to believe in the seriousness of the claim. [But this is an intuition, I may be wrong about that]

I just read the introduction of an article that corroborates this feeling and states that some combination of keys have special meaning (ART1). It is unlikely that all passwords have characteristic combinations that can be used as signatures since the sample sizes are too small. Another article is a bit old, but describes the methodology and the success rates in 83 to 92% range and states that keystroke patterns are an auxiliary mechanism (ART2). Biometric Solutions states clearly: "In general behavioral biometrics such as keystroke dynamics are less reliable than physiological biometrics" and "there can be no such thing as an absolute match with behavioral biometrics" (SITE1). Which are in line with my intuition.

Actually I would expect the typing of common words be easier as signature than passwords. On common words people will type something they are accustomed to. That is not the case of passwords.

I expect such an algorithm results in different profiles:

• If the person uses multiple keyboards.
• If the numeric part of the password is typed on keypad or in the numbers above the QUERTY part of the keyboard.
• If typed in a keyboard over a table or with a laptop on lap;
• If the password is very complex;
• If the password is changed frequently;
• If the password includes symbols and punctuation. On different keyboards the [ ] { } ' " | \ are in different positions. We have a lot of variability on those keys on notebooks of different brands. For example, in the keyboard I am using the question mark is next of the right shift key. On my notebook there is no question mark key... I have to press right alt + W to get a question mark.
• If the typer is like me. I type lighting fast. I am able to type faster than people can talk. But my typing style is crazy. I type only with 6 fingers. Depending on the inclination of the keyboard I type with different fingers and in different speeds.
• Due to the mood of the person.

From that I ask:

1. Your associate uses different keyboards?
2. Your associate password has characters that have different positions or sizes on different keyboards?
3. Your associate password is big and complex?
4. Your associate password is too small?
5. How often your associate change its password?

And then again, I agree with people here: The burden of proof is with the accuser. The accuser have to make a better argument than this. For an algorithm like that I would ask the company the test data on the model with sample size, false recoginition rate (FRR), false acceptance rate (FAR) to demonstrate that the keystroke pattern detection is accurate enough to be trusted. If they can provide this with decent sample size and low enough errors (and I doubt that) you can think in asking a test. Even DNA has caveats and exceptions.

I say that because many products left the lab poorly tested. And many companies buy without testing it. They believe that the selling company should know what they are doing. This is not a problem if we are mindful of that. For example, new operating system versions (Windows and Linux alike) are not trusted by default. We are mindful that many bugs will be found on them. We can get early access to new features under the risks of some problems. Which is acceptable for most applications with the appropriated level of control. If we know that we can prepare for it.

The problem is that most vendors try to hide the limitations of their products and tend to see 80% as close enough to 100%. 80% precision is good for monitoring and to ask additional security factors, but is not enough to full authentication. And most biometrics vendors I met are trying to sell biometrics as passwords. As the ultimate solution to security. Which is not the case. Not even close. Does not get me wrong, biometrics are cool and will be a great help in security. They are helpful in some scenarios to limit opportunities for the criminals. The biometrics in iPhone and Samsung was cracked with a little of dental mold, including fake fingers made out of social network pictures of the person (VERGE1). Even then is useful, if you forgot your phone on the table, the people in the office will not have access to it. It makes a targeted attack a bit difficult, but not much, but offers good protection from opportunity crimes, loss and theft.

Answer 4

I think the claim is somewhat ridiculous, both from a technical and juristical perspective, and I would be very surprised if they could successfully enforce their claim. Or, given the possible implications, if they even tried (they're probably only bluffing).

Insofar, I would politely tell them to go away, and forget about the whole thing.

What are the facts?

There is the allegation of your friend having shared his password with someone, more or less out of the blue. The allegation bases on some very questinonable numbers that are (presumably covertly? did your friend know about this before they accused him?) recorded using some kind of unspecified and presumably unreliable system.

Your friend testifies that he did not share his account info, and strong circumstantial evidence (all logins come from his home computer or his work computer, and from times when he worked) confirms his testimony.

The burden of proof is with the provider insisting that the user broke the terms of service, and unless they have conclusive, hard evidence, any such accusation is at best libel (which is actionable, therefore I doubt they will try to press charges).

Assuming a sufficiently accurate measurement, the presence of a keystroke pattern that matches is an indicator for the same person. The presence of a keystroke pattern that does not match is however an indicator for nothing. It can be shown trivially, live, at any time, that the same person can produce a dozen different typing patterns within a minute or two.

Your modern iPhone has a fingerprint sensor. This is a much more sophisticated biometric authentication mechanism with a much lower error rate, which is much harder to deliberately cheat on (assuming you use the right finger) and yet it regularly fails -- on my phone, about once in maybe 10 attempts.

Now, following the logic of this web application's provider, Apple should call the police because I stole my iPhone -- about twice per day! There is conclusive evidence after all... the fingerprint didn't match, so clearly I'm not the legitimate owner. This is ridiculous.

Depending on where you live, the mere covert recording of keystrokes may mean serious trouble for the provider already (they had better not be based in the US).

From a technical point of view, a desktop application can, without unreasonable effort, record keystroke dynamics at about 15ms resolution on a typical Windows PC. You can do better if you install a low level keyboard hook or a driver (good luck doing that in Javascript or in a browser plugin), but reasonably receiving messages and recording the message time at 15.6ms is as good as you get.

Calling GetMessageTime() right after receiving WM_KEYDOWN or WM_KEYUP is pretty much the most accurate way of getting the message time (you could use QPC, but to what avail... the accuracy is limited by the message, which already contains a timestamp, a higher resolution timer would only give more digits, but not more precision).

If I do this in a simple 10-line program which does nothing but print out the message time while typing "the quick brown fox jumps", and take deltas, then I get as a result that my dwell time is 2 ticks +/- 1 tick, and my flight time is 3 ticks +/- 1 tick (expressed in units of 15.6ms).

Unless your password has a couple of thousand characters, this is way too imprecise to tell anything. A dozen keystrokes, each taking 2 or 3 ticks? Excuse me? For hard, conclusive evidence? You could as well read tea leaves.

Yes, the accuracy could be improved by adjusting the system scheduler's interval. But again, this is out of the scope of some thingie that you run in a browser. Also, consider that for a browser plugin or a piece of Javascript, the browser's logic is in between receiving events and you seeing them, too. Which will result in an unknown (and possibly non-deterministic) delay, further blurring the measurement.