My first thought is that this can trivially be spoofed by installing a keylogger with playback functionality, but at that point a password wouldn't save you, either.
Could you keylog/model a user when using another machine i.e. a public library computer, then use that model to simulate the user (playback) elsewhere? Do you have to capture them typing the 'passphrase'?
"We examine the problem of keyboard acoustic emanations.
We present a novel attack taking as input a 10-minute sound recording of a user
typing English text using a keyboard, and then recover- ing up to 96% of typed
characters. There is no need for a labeled training recording. Moreover the
recognizer bootstrapped this way can even recognize random text such as
passwords: In our experi- ments, 90% of 5-character random passwords using only
letters can be generated in fewer than 20 attempts by an adversary; 80% of 10-
character passwords can be generated in fewer than 75 attempts.
Your first thought is correct. This fails. Trivially.
If you got through the problem of people's keystroke speed varying with local factors, you'd wind-up with a situation where not only is your "password" the same on every site, even sites you visited without logging into could "sniff" your "password".
And it differs quite a bit based on _what_ I am typing, too. Plus the tactivity(?) of the keyboard factors in, because as soon as I have feedback that the key was registered, I am on to the next one.
It's sometimes said that if you aren't embarrassed by your product at launch then you've waited too long. It's important to get early feedback, and build on early reactions and responses.
Likewise, by making ideas like this, along with an early investigation, perhaps someone can build on it, or throw out another idea, and perhaps people can work together to find a good solution to the mess that is current user identification.
Or would you rather people beavered away in secret, never sharing ideas, never sharing their results, and never working together?
Especially if a Dvorak user is forced to use Qwerty on another person's computer. At that point, they become completely unable to log in via this method.
The major problem with this scheme is that if I type it "wrong", I have no conscious way of recalling how to type it correctly. In fact, my natural cadence will likely be thrown off even more by the stress of not being able to log in. I would quite literally have to walk away from the computer, do something relaxing for a few hours, and then walk back hoping that I type naturally again.
I think gatekeeping example serves just as a proof of concept. It could be more useful for continuous monitoring. For example to tell you that somebody else may be using the computer that you are still logged in to.
This is the more compelling case for me. Train it across an organization and then you can monitor who typed what. In operations, this is my killer use case.
The problem is that we have 'server' machines and a system which requires 'root' access to do certain things. We'd love to know who on the operations staff did something on the server (a workaround is to set an environment variable but which works in the 'normal' case but fails if someone is being a bad actor). So you train it up across the org, and then when ever you have a session where the signal from the type sig doesn't match the logged in UID, you alert it (or log it). SO instead of 'root just changed the date to last year' you get 'Chuck just changed the date to last year'. That would be a very very very useful tool to have in one's toolbox.
if someone is misbehaving (and is aware of the system), I would imagine with a certain discipline (say, rotate the keyboard 180degrees and try to touch-type, or just hunt-n-peck with some significant random variation) it would be reasonably easy to 'fool'. That is, it would be unable to classify it as any of the known users.
I'd think it could be more robust than the 'remember to set env X=y before doing stuff' especially for real-time oh shit fix everything moments, as a sort of passive identification, but couldn't hope to stand against a determined adversary.
I suspect you are right, however note that the proponents of this technology often claim that they can tell who you are even if you do these sorts of things.
Isn't the point that it would be rather difficult to impersonate someone else? I mean, the system would realize that "someone" is misbehaving and can flag/log the actions appropriately or even disallow them entirely.
Imagine a typing tutor website. You start typing a few warming up exercises, then the system recognizes you and selects the material according to your progress so far. No need to log in whatsoever.
The late Michael Crichton wrote an Apple II program in the mid 80's using intra-letter timings to check if the person typing a password in was the person who set it. Worked pretty well; better if improved to sample multiple times, use long phrases, and adjust tolerance.
Why? The algorithm could acknowledge and adapt to a changed password, and try to learn the timings anew, instead of expecting the same speed as with the older one.
I experimented with this a couple of years ago when I saw that video, by implementing an ajaxy authentication system that timed keystrokes. Ignoring the fact that you could probably keylog the heck out of it, I found that a single user's typing patterns varied substantially, depending on typing skill, input device, and so on. Oh, well.
So for authentication this doesn't seem like it could completely replace the password. That said wouldn't it be interesting as a way to tell when someone is stressed out or tired. For instance I know when I'm super mad my spelling goes down the pot.
Remember gmail's arithmetic questions after watershed to prevent drunken users writing 'regrettable' emails? This could be another angle to provide the same functionality.
The biggest problem with this is that it requires uniqueness to be traded for error tolerance. People are going to have different typing styles depending on their mental and physical state, and their typing styles will change over time. In addition, while the space of possible typing signatures is very large, the space of actual typing signatures is much smaller. So we simultaneously have to assign each person a blob of signature space which is big enough that it can positively identify them regardless of whether they've had their morning coffee (or, god help them, they cut their finger or break their arm), and small enough that we don't have so much signature overlap as to make the system useless.
In either case everybody will have to have a fallback password in case their stride is off one day. If the system works well, then that password will be rarely used. A rarely used password is harder to remember than a regularly used one, so people will choose weak passwords for the fallback.
So the only way that this system has any chance of working without grossly compromising everyone's security, is if it barely ever positively identifies anyone.
Of course, even if it did work perfectly, it would be the equivalent of having the same password everywhere. In that case, why not just memorize one strong password?
This idea has some history to it, I remember reading that they tried to use this same analysis in the trials against Kevin Mitnick. Some clever sysadmin had recorded Mitnick's telnet activity (as it went across some crappy modem) and claimed to be able to identify him based on the timing of different keys. The judge threw it out as not being reliable evidence.
Wish I could remember where I read that; it was some book about hackers in general.
I built some network security software in the early part of the 2000s. Around 2005, a local guy built a keystroke pattern recognizer utilizing neural networks to learn your keystrokes and was able to correctly identify who you were after a minimal amount of learning (typing). He brought it buy to see if we were interested in licensing it and using it in our product.
While somewhat of a black box demo, we were able to play with the technology. We tried a ton of stuff to fool the system (physical only, we didn't use keystroke macros or anything like that) and it would correctly identify us every time. It was showing us the probabilities as they'd change and it was uncanny how it would immediately know that I started typing instead of a coworker.
So, it's not only probable/possible/exists, it's only drawback is the lack of necessity. Outside of the the highly paranoid using it to prevent outside intrusions (government mostly), not many systems need it due to lower-end attacks that are much easier to do and typically successful enough.
How many people were there? Did he have any way of estimating the entropy of the signatures? Did you try the demo over multiple days, and at different times of day, to see if it continued to identify you correctly?
>it's only drawback is the lack of necessity
No, that's not the only drawback. Be very careful when talking about cryptography and security never to assume that you are aware of all of the weaknesses unless you've got a formal proof.
One very big drawback I can think of off the top of my head is that it would essentially be like having the same password everywhere, and being completely unable to change that password. If someone records your typing style once, they will be able to get to absolutely everything that identifies you based on typing style. At least with retina scans and fingerprints, there are mechanical obstacles to producing a facsimile.
That's true. Proofs rely on assumptions, and in the real world, those assumptions may hold in all cases. Failing to recognize that will lead you to thinking very silly things, like that that Gödel's incompleteness theorems have deep philosophical implications.
As an extra layer of security, not the 'singular' layer of security, the drawback you mention doesn't apply. It would have uses outside security too, for example user identification and profiling purposes on websites. I often wonder about sites where users usually type in content, and what information could be gleaned about users by their operators.
We had 5 or so people playing with it over a couple days. We didn't have any insight into the code - how often it polled, how much it changed, the window of valid keystrokes, etc. - just the ability to use the demo software and see various metrics.
You're right, it's not the only drawback. I just meant that there are many vectors of attack when it comes to network security and so many fail at those that this might be less gain than one might assume at first thought.
Yes. A friend of mine has a patent on a gun that fires only for one person. The gun has been extensively tested and works great. The fire/no-fire decision is based on the way the trigger is pulled.
Gun manufacturers hate it because it has scary gun control implications. But if/when it does become available New Jersey police will all use it.
Keystrokes should be way more distinctive than a trigger pull.
That's fascinating. Can you share more detail? How do they key it to the individual? Do people really not pull the trigger differently in high-stress situations vs at the firing range?
Could also be measuring the galvanic skin response and the like to try to further narrow it down. But I don't know how well that works for reliability since stress can change it i think.
It does seem like even a very consistent shooter would be too different between slow, aimed shots and rapid firing. Perhaps one would be able to record a great number of pulling patterns in different stress levels, and still have the lockout be effective?
Couldn't this sort of thing be solved via some kind of very short range radio based lock? For instance, a transmitter build into a ring that can only "unlock" the matching gun.
A comparable but significantly lower tech solution is using a high-strength magnet integrated into a ring which manipulates some part of the trigger mechanism, unlocking it for use, eg: http://www.tarnhelm.com/magna-trigger/gun/safety/magna1.html
It's not keyed to a specific weapon, but it seems like it would help prevent the most common dangers of either a kid finding and using it accidentally, or in an actual combat situation, being disarmed and having it used against you.
The only major benefit to per-device keying would be (marginal) additional security, and increased auditability
Screenplay for the opening scene of Bond 24 (Skyfall is already in post-production).
James Bond is chasing a villain. Draws his gun to aim for a long range shot. (Gun has a little green LED on the side)
Out of the side lunges a henchman who engages Bond in hand to hand combat. The gun goes skidding away.
Henchman wins combat over Bond and runs to the gun. It appears Bond is done for. Henchman draws gun. The LED is red, but the henchman doesn't notice.
<CLICK>
Henchman thinks the gun is out of bullets and flings it at Bond as a projectile and runs at him to reengage hand-to-hand combat.
Bond deftly catches the gun. He draws it. The LED is green.
That idea and even the scenario you describe has actually been used numerous times in action movies (though admittedly usually using a different principle like fingerprint reading), including the James Bond franchise. For example, in License To Kill Q invents a gun with a palm reader that can only be fired by the person programmed in. It has green lights on the grip.
The first example that comes to mind for me is a scene in the 2007 movie Shoot 'Em Up; the protagonist's workaround for using a dead henchman's thumbprint-verified firearm is to use their severed hand (of course).
Is it an active thing? Does it learn and adapt to your pull style as you grow as a marksman? A lot of my range time is spent trying to smooth out my trigger pull. As I get better, does the gun recognize this change in pull style?
Your writing style can identify you. 'Jstylo' is a tool that detects authorship. 'Anonymouth' is a tool that spoofs authorship (ever wanted to write HN replies as if you were JK Rowling? You can do it.)
yes. i did it back in 6th grade (i.e. somewhere in 1997 probably) using Turbo Pascal without all this fancy/shmancy neural stuff. just 3 dimensional array, one plane for each user and get average time between key strokes. It was good enough to detect me, my mom, father and my friend.
It also have downside - your patter will change overtime and if this is sole authentication measure - it will fail eventually. I would use it as fuzzy monitoring to detect stolen credentials instead.
I've once evaluated a product like this pretty extensively. This was about 5 years back and I think the company is now called Admit One Security.
Surprisingly enough, that company's userbase absolutely hated carrying tokens and they wanted to bend over backwards to accommodate them. The entire point was to provide an alternative way of doing 2-factor authentication.
The bottom line is that it mostly did work as advertised. The place where it struggled were poor typers of the hunt and peck variety. They just didn't have a good enough pattern and the failure rate was fairly high.
Another weak point would be any type of hand injury or even being under the influence would throw it off completely.
I liked the approach a lot, but ultimately, when it does fail, its extremely frustrating to the end user, since
they don't really understand what they did wrong.
I worked for a company that makes test taking / proctoring software that attempts to do this, I didn't work on the product myself but it seemed a bit of a trainwreck as they would always be having to do overrides for people who couldn't make it past the typing authentication (which was based on a previous sample of their typing), it measured pace, speed, etc.. the company itself wasn't that great so not surprising their implementation of this wasn't optimal, however its an interesting concept.
The way I type changes dramatically from day to day, depending on my emotion. Sometimes I top very choppily at 35wpm, and sometimes I type like a waterfall flowing over rocks in waves at 120wpm. There's no way that this method would work reliably for me.
OK, that may work with a hardware keyboard, but what about a manner of typing on on-screen keyboards? Will I be able to log in from the tablet or phone?
85 comments
[ 3.2 ms ] story [ 159 ms ] threadErh.. no thank you.
Yeah, no thanks.
Checking long posts on news sites or blogs just to make sure it is the writer would be interesting, but boring and not worth it.
http://www.cs.berkeley.edu/~tygar/keyboard.htm
Now, visit it from a different browser or computer and make another comment - it would log you in as you again, somehow.
Errors would likely make it unpractical, but it'd be an amusing demo for the unaware.
If you got through the problem of people's keystroke speed varying with local factors, you'd wind-up with a situation where not only is your "password" the same on every site, even sites you visited without logging into could "sniff" your "password".
0-factor "identification"!
I.e. THIS POST TO BE DOWNVOTED?
Vs SHOULD THIS POST BE DOWNVOTED?
Likewise, by making ideas like this, along with an early investigation, perhaps someone can build on it, or throw out another idea, and perhaps people can work together to find a good solution to the mess that is current user identification.
Or would you rather people beavered away in secret, never sharing ideas, never sharing their results, and never working together?
The problem is that we have 'server' machines and a system which requires 'root' access to do certain things. We'd love to know who on the operations staff did something on the server (a workaround is to set an environment variable but which works in the 'normal' case but fails if someone is being a bad actor). So you train it up across the org, and then when ever you have a session where the signal from the type sig doesn't match the logged in UID, you alert it (or log it). SO instead of 'root just changed the date to last year' you get 'Chuck just changed the date to last year'. That would be a very very very useful tool to have in one's toolbox.
http://aplawrence.com/Basics/sudo.html
EDIT: noticed the 'root', making a new assumption this is a windows server box.
Without going into operational specifics, the answer is that this doesn't scale.
I'd think it could be more robust than the 'remember to set env X=y before doing stuff' especially for real-time oh shit fix everything moments, as a sort of passive identification, but couldn't hope to stand against a determined adversary.
I experimented with this a couple of years ago when I saw that video, by implementing an ajaxy authentication system that timed keystrokes. Ignoring the fact that you could probably keylog the heck out of it, I found that a single user's typing patterns varied substantially, depending on typing skill, input device, and so on. Oh, well.
In either case everybody will have to have a fallback password in case their stride is off one day. If the system works well, then that password will be rarely used. A rarely used password is harder to remember than a regularly used one, so people will choose weak passwords for the fallback.
So the only way that this system has any chance of working without grossly compromising everyone's security, is if it barely ever positively identifies anyone.
Of course, even if it did work perfectly, it would be the equivalent of having the same password everywhere. In that case, why not just memorize one strong password?
I'm going with "no" ;-)
Wish I could remember where I read that; it was some book about hackers in general.
While somewhat of a black box demo, we were able to play with the technology. We tried a ton of stuff to fool the system (physical only, we didn't use keystroke macros or anything like that) and it would correctly identify us every time. It was showing us the probabilities as they'd change and it was uncanny how it would immediately know that I started typing instead of a coworker.
So, it's not only probable/possible/exists, it's only drawback is the lack of necessity. Outside of the the highly paranoid using it to prevent outside intrusions (government mostly), not many systems need it due to lower-end attacks that are much easier to do and typically successful enough.
>it's only drawback is the lack of necessity
No, that's not the only drawback. Be very careful when talking about cryptography and security never to assume that you are aware of all of the weaknesses unless you've got a formal proof.
One very big drawback I can think of off the top of my head is that it would essentially be like having the same password everywhere, and being completely unable to change that password. If someone records your typing style once, they will be able to get to absolutely everything that identifies you based on typing style. At least with retina scans and fingerprints, there are mechanical obstacles to producing a facsimile.
You're right, it's not the only drawback. I just meant that there are many vectors of attack when it comes to network security and so many fail at those that this might be less gain than one might assume at first thought.
Gun manufacturers hate it because it has scary gun control implications. But if/when it does become available New Jersey police will all use it.
Keystrokes should be way more distinctive than a trigger pull.
EDIT: Michael Recce is his name, http://www.njit.edu/news/2003/2003-125.php
I would also be fascinated to learn more.
It's not keyed to a specific weapon, but it seems like it would help prevent the most common dangers of either a kid finding and using it accidentally, or in an actual combat situation, being disarmed and having it used against you.
The only major benefit to per-device keying would be (marginal) additional security, and increased auditability
James Bond is chasing a villain. Draws his gun to aim for a long range shot. (Gun has a little green LED on the side) Out of the side lunges a henchman who engages Bond in hand to hand combat. The gun goes skidding away. Henchman wins combat over Bond and runs to the gun. It appears Bond is done for. Henchman draws gun. The LED is red, but the henchman doesn't notice.
<CLICK>
Henchman thinks the gun is out of bullets and flings it at Bond as a projectile and runs at him to reengage hand-to-hand combat. Bond deftly catches the gun. He draws it. The LED is green.
Cue gunbarrel sequence.
http://www.youtube.com/watch?v=4_XPjcAFuQY
I wonder what other 2000AD technologies might start cropping up soon. We already have riot foam, however from what I read it didn't work very well when first used. http://discovermagazine.com/1999/apr/warwithoutdeath1610
Does it also detect the changes under duress?
Really fascinating stuff.
It also have downside - your patter will change overtime and if this is sole authentication measure - it will fail eventually. I would use it as fuzzy monitoring to detect stolen credentials instead.
Surprisingly enough, that company's userbase absolutely hated carrying tokens and they wanted to bend over backwards to accommodate them. The entire point was to provide an alternative way of doing 2-factor authentication.
The bottom line is that it mostly did work as advertised. The place where it struggled were poor typers of the hunt and peck variety. They just didn't have a good enough pattern and the failure rate was fairly high.
Another weak point would be any type of hand injury or even being under the influence would throw it off completely.
I liked the approach a lot, but ultimately, when it does fail, its extremely frustrating to the end user, since they don't really understand what they did wrong.
1. You ask a user to type in a couple of words. 2. Create a profile for them.
so that when you sign up for something you:
3. verify they are who they say they are as they fill out the form. 4. can skip captcha? (i.e. the form filling is the captcha)
?