Skip to content



What does TickStream.KeyID do?

TickStream.KeyID adds another dimension of security to the very commonplace (but weak) username/password method of authenticating users. It measures the effort involved in your finger muscles’ activity when entering a password and compares it to an established library of same-password effort profiles to determine if it was really you who entered your password in order to determine whether or not to grant system access.

How does it work?

TickStream.KeyID mathematizes your effort when entering a known string of characters and establishes a degree of closeness that resembles your unique behavior, validating that it is actually you who entered the password – the underlying how is patent-pending and a trade secret.

Why do I need it (i.e., why aren’t passwords enough)?

Today’s passwords simply are not effective. Check the news! Intensity Analytics offers a simple, economical way to make a password stronger. Research shows that 90% or more of enterprise cyber-attacks are the result of stolen credentials. Researcher Alan Paller at SANS Institute reports 95%, and Trend Micro reports over 90% of enterprise breaches are the result of stolen credentials. Your behavior is what differentiates you from anyone else who has your credentials – TickStream.KeyID adds your behavior as a multifactor authentication layer that essentially eliminates the chance of success in the aforementioned 90%-95% of enterprise cyber-attacks.

What operating systems / environments does it run on?

TickStream.KeyID runs in a browser, with no plug-ins or agents, on any operating system, on Microsoft Windows desktops, on Active Directory, and third-party enterprise platform solutions, such as F5 BIG-IP APM.

What makes this different than biometric authentication techniques like fingerprints?

Behavior! TickStream.KeyID does not capture any Personally Identifiable Information (PII), such as a fingerprint. While your unique behavior patterns theoretically could be stolen, doing so is worthless, because the act of authentication is recreating that behavior at match time. For example, you can steal the movement diagrams for a ballerina, but you can’t dance her dance the same way she does. Additionally, TickStream.KeyID does not require any special hardware, as do fingerprint or iris scanners. Hardware-based systems are costly, difficult to deploy and maintain, require training, and all too often are not where you need them to be (e.g., on a public or shared computer). The metrics of behavior are both anonymous and changeable. They are not used anywhere else. You can always switch to another behavior set, but you can’t change your fingerprints or iris patterns.


How do you install it?

Over the web, it’s a simple addition of several lines of standard JavaScript code to a webpage. For desktop application, it’s calling a series of common DLL’s. For other platforms, such as Microsoft AD/FS or F5 BIG-IP APM, we provide wizard-driven installation programs. All interfaces use standard web services architecture and are easily accessed both for profile building as well as for run-time analysis.

Will TickStream.KeyID work cooperatively alongside other authentication products?

Yes, it is designed to do that. All interfaces are standard and the architectures are Best Practices and straightforward. Our product is designed to collaborate with, and not compete with, other approaches. We want to join and become a layer in the “layered defense” cyber security solution architecture quest. We don’t aspire to be the only layer.

What if I use two different keyboards (laptop v full-sized keyboard)?

TickStream.KeyID can detect the input device to determine whether or not there is a substantial change in typing behavior from one device to another. If so, a unique profile for each keyboard utilized by an individual would be established. If the keyboards are truly different, you can always build a separate profile for each one you use.

Does it work for everyone?

No … but TickStream.KeyID does work for almost everyone. As long as one is able to act in a consistent behavioral manner with the keyboard, and as long as an adequate profile can be established that is reflective of the user’s unique behavior, it works fine. People without fingers, or with certain disabilities, will not be able to use TickStream.KeyID. Like all authentication methods, there is no 100% solution. Instances where there is a temporary inability to perform within the realm of your normal behavior, such as a broken finger, may be supplemented with an alternate form of multifactor authentication for an interim period of time to allow continued access based upon the internal guidelines or policies established in your organization. But we have a 100% workaround for those rare circumstances that can be separately addresses — please let us know.

Does it work in all languages?

TickStream.KeyID has only been tested with English language keyboards at this time. If you would like to test an environment in another language, our development team would be interested in speaking with you.

Does it work if I am really tired or impaired and can’t move the way I normally do?

Again, as with all authentication methods, there is no 100% solution. Instances where there is a temporary inability to perform within the realm of your normal behavior as a result of fatigue or intoxication, for example, may be supplemented with an alternate form of multifactor authentication for a while to allow continued access based upon internal guidelines or policies established in your organization.

Do I have to enter my password exactly the same way every single time to be granted access?

No. TickStream.KeyID measures your instance behavior to a degree of closeness to your pre-built profile in the Cadence & Habit Library. Depending on the level of security required, this can be set at very tight or reasonably tight levels in order to achieve balance with usability and security requirements. You do not need to behave “exactly” the same way every time, but there must be reasonable consistency in your collection of efforts when entering your password each time. After that, we actually expect that you will enter your password slightly differently each time.

Will I still need to change my password periodically?

A better question is: do you HAVE to change your password on any periodic basis? That answer depends on the rules of your organization. If the password changes, then obviously TickStream.KeyID will go about relearning your muscle movement patterns with the new letters – again, this can be completely frictionless to the end-user based on how the program is set up. One helpful capability we bring to the market is that the era of HAVING to change the password characters is now bygone, because we don’t look at the characters anyway. Your behavior is already onboard you, and doesn’t change every 90 days!

If TickStream.KeyID requires access to a server and I’m on an airplane, how does that work?

We provide a cached-credentials alternative to accessing the server real-time to permit use of the system when a remote the Cadence & Habit Library cannot be reached.

Why is this so vital for single sign-on providers?

As the saying goes, if you put all your money in one vault, you have to protect that vault with even more care and attention. Adding TickStream.KeyID and UEBA (User and Entity Behavioral Analytics) frictionlessly is a natural, no-brainer, defense-in-depth smart move

Can’t somebody else type the way I do?

Yes. There are probably a number of people among the 7¼+ billion on the planet can probably do that — but our solution is a probabilistic one that works at a very high percent of success. Just like the lottery. Somebody wins it, but not you. The chance that somebody can type your password your way in your environment successfully in one or two tries is extremely unlikely – but theoretically possible. This is true of every probabilistic system, even including fingerprints. If you have a cheap reader and somebody’s prints are close to yours, they might get in. With deterministic systems such as a brass key in a lock, you either have the key or you don’t. The problem of course is that you have to have it. With you. Somebody else could have it. But nobody else around you routinely has your behavior – thus the probabilistic approach is far more secure in practice, and when you factor in economics, it’s vastly superior.

Can I paste in the strings and skip the typing?

No. TickStream.KeyID never looks at the characters. Never sees them. So pasting in the characters is of no help, and the finger movement effort of keying V is not the same effort as typing the actual text. Pasting is not the same behavior as typing, just as walking around a puddle is not the same behavior as jumping over it.


What happens if someone hacks the TickStream.KeyID server?

One of the most important aspects of this technology is that it doesn’t create a problem to solve a problem. Many security solutions add new factors or data elements that require additional security to protect, such as the kind of fingerprint data that was stolen from OPM, or device tokens that require physical security (and expose the user to identification by a third-party by merely possessing the device). TickStream.KeyID is just gathering data that is already there: the behavior of the user. So, not only does this allow the user to clandestinely identify themselves, it also means that the server contains no useful information to a hacker. The only things stored are second-order, derived statistics about behavior – imagine listening to a piano recording: there is no information in there about the shape of the pianist’s hands, but that is critical to reproducing the behavior. You could steal a copy of the recording, but it doesn’t help you to play the piano the same way. Since we don’t care about the result components (the letters typed or the notes produced), only the effort metrics are used to produce the match opinion. This means that there is nothing worth stealing. So, rather than creating a new vulnerability in the protection process, we devalue the most common attack vector.

Can this be defeated by a machine or keyboard logging or some other form of macro or automation?

Whenever we get these edge-of-the-universe questions, we always respond: “yes.” It would be possible to build a humanoid/avatar that could somehow learn to mimic the way you move and type the way you type – but it would be pretty hard to sneak that machine past the guard at the gate. Keyboard logging, the use of macros or other forms of automation simply don’t work for a variety of proprietary reasons. First, the macro writer would have to know not only the characters but the metrics of how they were typed. We look for certain variations in keyboard cadence because not only can nobody else type like you, not even you can type like you (although you are usually pretty close to what you reflexively do). We know how to measure that requisite closeness as being accounted for by human activity and can tell it from machine activity. If you like to discuss this further, give us a call.

Tell me how this can be defeated by people with bad intentions so that I can prevent that?

In theory, the TickStream.KeyID approach can be defeated — but those cheating routes can also be detected and blocked. One of the founding promises of our technology, across its entire planned-for range of uses, is that both the organizations that use it, as well as the people who rightfully are entitled to use it (e.g., employees, customers, etc.), together in good faith intend to achieve a very tight gating mechanism which will keep the bad guys out. And the jobs from going away. And avoid the cost of liability damages, the loss of market and reputation, the loss of jobs, etc. For example, if two people collaborate to build one person’s profile, that will fail because the algorithm will not know who is who. If we return a “Not You!” result, and then that result is intercepted and changed to a: “Good to Go!” signal, TickStream.KeyID will fail in purpose because it was improperly deployed. Finally, we have developed a comprehensive set of rules to ensure the correct building of simple, easy-to-remember, passwords which can be typed without thought or intention. Follow those rules, and it’s extremely hard to defeat TickStream.KeyID.

Cadence & Habit Library / Profiles

What is the Cadence & Habit Library?

This is the library where all profiles are stored. These profiles only contain second-order effort metrics and no character data — we never get or see those letters. Usually the Cadence & Habit Library resides in the Cloud, but it can be kept locally in a cache — there are a number of technical options which we are happy to discuss.

What if my familiarity with my typing patterns becomes better (or different) over time and therefore my typing habits slowly evolve?

We have an advanced machine learning engine which constantly monitors changes both during the profile building process as well as, optionally, on an on-going basis, so TickStream.KeyID will stay up with you.

How long does it take to build the Cadence & Habit Library?

This can be built in two modes – up-front, or wake-up. The latter is easy. When TickStream.KeyID has seen enough samples with sufficient cohesion, the opinion engine turns itself on automatically, and the user is never aware that the system is in use. For up-front requirements, it typically takes about 10 minutes to type the 12-20 samples normally needed to build a statistically sufficient profile library.

What if I sneeze when I’m typing or make some kind of mistake when building my library?

That particular single profile building attempt will fail and be automatically ignored by the system as being “not yourself.” It’s no different than coming to the office with a bad cold and people remark that you don’t talk like yourself. They know congestion; we know cadence.

How much protection is required for the Cadence & Habit Library?

Although we of course put the Library in a highly encrypted and encoded way, actually no protection is technically required because there is no value in the metrics we store. The value of the metrics is in setting up the challenge to any prospective user, including you, to match those metrics, real-time, when you type.

How does my behavior profile get created?

The ideal way for behavior profile creation to take place is by means of the entirely frictionless implementation of TickStream.KeyID’s engine, allowing it to run in the background — invisible to the end user — to collect a sufficient volume of password entries to learn a user’s unique behavior. Typically, this requires a minimum of around 12 or so entries of the same password string of characters, and a password length of a minimum of ten characters in the password, but usually in the 12-18 character (practical) range, and conforming to a set of guidelines that are separately available. The purpose of those (important!) guidelines is to give users the confidence that they can type something that is both comfortable and easy, yet with sufficient variation so as to feature their behaviors. It’s an easy process.

Tell me why a simple password like: “Super Bowl 50!” Is better than “qnR#!90_zM8”?

The problems with the complex passwords are many: They are hard to remember. They are hard to type. They usually have to be written down to be remembered – and therefore are easily stolen. The problem with “complex passwords” is that the focus is on the text. TickStream.KeyID never looks at the text and never has access to it and doesn’t care what’s typed. What it does care about is how … simply quickly reliably comfortably easily smoothly thoughtlessly effortlessly painlessly frictionlessly … you type. So pick your team and think about the Super Bowl — it’s a better way.


How much does it cost?

TickStream.KeyID is an affordable solution that can be delivered in several types of implementations. In a SaaS application, costs typically average just a few dollars per month. Alternatively, a per-instance user fee can also be established where your organization is charged each time a successful login is achieved. You can also install TickStream.KeyID with a Server License or Enterprise License.

Can I test it first?

Sure! We have a formal testing protocol. Being scientifically and statistically rigorous requires careful thinking and an organized approach. We can tell you what we, and outside experts, have used to do this testing and you can replicate that for yourself, as you like.

What if I want to resell it to my customers?

We would love that – please give us a call.

Can I purchase exclusivity in down-chain specific markets into which I sell?

Yes, please call us for details.

Can I license this “white-label” to embed and/or rebrand in my own products?

Yes, please call us for details.


How long did it take you to create this and why is it so difficult to do?

Over five years. We wound up building it the wrong way first, just as many others have done, and now clearly understand why the “time-only” approach is a fail. See below. Initial development was followed by a year of comprehensive testing, with an approach designed and supervised by two of the country’s leading biometric statisticians — PhD department chairs at George Mason University. Then integration. Then attack defense development. Then distribution. Then multi-platform support. Then developing references in significant vertical markets. And so on … as all the world came to discover that biometric multifactor authentication is a completely different thing than behavioral analytics.

Hasn’t this already been done before – I read about this all the time?

Again, many people have tried to do this for a long time. The problem is that they’ve used straight timing metrics. You can read all about that in Wikipedia: Hang Time; Dwell Time. Flight Time. That route doesn’t work; that dev road is littered with attempts. You can indeed measure the time, but doing that is not enough to provide differentiation. We had to develop a variant of the same kind of mathematics that rocket scientists use to cause space probes to travel past planets and grab hold of just enough gravitational pull to fling them in a new, exact direction at a higher speed. We do something similar. It took a long time to figure that out, and so we came to use geospatial equations and algorithms. The secret is simple to state, but it took us a number of years to develop and test, and then have externally validated. In the end, we learned how to mathematize effort. Just like a camera pixelates your face and then digitizes that color information and stores it, we digitize the many-dimensions of involuntary muscle movement from which we build highly complex mathematical models. These serve as “photographs” of your effort just like a picture serves as a photograph of your face. That approach works, we discovered it, and it forms the basis for our patenting activity. It IS rocket science after all!

How was the technology tested to validate its performance in a scientific way?

We engaged two well-known experts from George Mason University, Dr. Donald Gantz and Dr. John Miller, to study the reliability and performance of TickStream.KeyID. They designed a blind test protocol to gather the source data and analyze the predicted behaviors of the model against the actual results from the software engine. As the professors reported in their Conclusions, “Drs. Gantz and Miller have examined the TickStream.KeyID software product, and found it yields good results, which places the reliability and performance within the range of, or better than, other traditional authentication solutions. Importantly, as we have reviewed those other technologies, TickStream.KeyID achieves these results without special hardware, and in practice, little to no user training... Our computations show both that the current implementation of the software engine can greatly reduce the probability that an impostor can successfully use stolen credentials, and if the users are willing to accept a higher threshold of rejection, it can reach a 0% rate, effectively blocking all impostors.” The study is available on request.

Do you have plans for desktop version for Mac or Linux, etc.?

Not right now, because there is not as much market demand for the desktop versions running on those operating platforms. Over the web, of course, the nature of the end-user platform doesn’t matter and so we are already compatible with basically all normal computing devices, including full-size tablets.

What if I have ideas for future improvements?

Send them in … if they’re unique and good enough, we will happily return licenses or cash!