101

When I was young, and had just started out in my software-development career 20 years ago, I wrote a little bit of code on my Amiga that took a password, but also recorded (within some threshold), the speed at which each letter of a password was typed.

This meant that, not only did the user have to type in the right password, they also had to time the key-presses. To test it, I'd have a rhythm in my head and could consistently re-type the password every time. However if I just typed it out regularly, or slowly, it was not accepted.

I am no security expert (my programming lies in less-difficult areas, thankfully), but I just suddenly thought about that program I wrote when I was young and whether it was a viable addition to security these days, or whether it's not even worth thinking about.

Tap - Taptaptap - TapTap -- Tap.

  • 58
    Potential concern: accessibility. – Mathieu K. Apr 28 '16 at 23:50
  • 9
    coursera.com, a site with free/paid college-level courses, does exactly this before each exam to ensure the correct person is taking the exam. Passwords can be shared, key-timings cannot (not easily, anyways) – BlueRaja - Danny Pflughoeft Apr 29 '16 at 4:53
  • 49
    Good for musicians and keeping millitary grade secrets safe, bad for everyday use. – Pharap Apr 29 '16 at 6:45
  • 14
    It would for sure increase my frustration since I often type passwords with one hand only, and also on logon failure I go slow and make extra sure I didn't mess up. Also qV519[YW;BAZE*qvjj11 doesn't lend itself to a rythm easily ;) Oh and password managers of course. – PlasmaHH Apr 29 '16 at 8:15
  • 13
    I actually implemented such a system using machine learning, but I found that it is way too unreliable for short inputs like passwords. However, it can be fairly accurate (up to 95% detection rate) when given more input (e.g. a longer facebook post). So it can be used to enhance security after a login, e.g. to check if somebody unauthorized just started using the computer. Then you can ask for the password again, just to be sure. – TheBrain Apr 29 '16 at 9:35

14 Answers 14

100

The term you are looking for is "keystroke dynamics" or "keystroke biometrics" and is an interesting and growing field.

The idea is that an individual types certain keys in a certain way that does not change much over time. If you can map those dynamics, then you could, potentially, do away with passwords altogether and simply get the user to type anything.

  • 49
    I heard that during the Second World War the Allied forces spied on the Germans with a hidden microphone in the German message room. The operators were forbidden to talk but the Allied decoders could actually recognise which operator was typing as well as the majority of their messages by the sound of their typing alone! They gave each operator a nickname as they didn't know their actual identities. – CJ Dennis Apr 29 '16 at 5:26
  • 9
    @CJDennis Sounds logical. Those kind of attacks are even still used nowadays. For example: Time the keystrokes of SSH sessions (just by timing the moments of network traffic, not the actual contents) and compare them with common typing patterns of your victim ... or start analyzing them from scratch. – Num Lock Apr 29 '16 at 6:24
  • 6
    @CJDennis They certainly used similar techniques when listening-in on encrypted Morse traffic (see Keystroke Dynamics on Wiki and notes on a listening station). – TripeHound Apr 29 '16 at 10:39
  • 19
    The only drawback to this system is that I just changed my work password. I'm typing it slowly and deliberately now as I'm learning it. In another week or two, I will have developed new muscle memory and will be able to type it much more quickly. Keystroke dynamics would require that I labor through it for the next 90 days until I change it again, and that would be very, very irritating, as well as making it easier to shoulder surf. – FreeMan Apr 29 '16 at 12:35
  • 7
    The correct way to use this, as with any supplemental biometric marker, is to record a confidence level that the individual accessing the system is who they represent that they are. If the confidence drops below some threshold, alert them through a preselected communication channel (like email) that there is some concern that someone unauthorized may have accessed their login info (at time x through system y, so they have some way to determine if it may have been them). It would be offputting for most uses, but I'd be OK if (say) my bank did that. – Jason Apr 29 '16 at 17:43
87

I think it would be very, very annoying to legitimate users of your application or website. Things like a broken finger, or just holding a sandwich in one hand, would make your login unusable. Additionally, you should encourage the use of password managers, which will either send keystrokes extremely quickly, or will not send keystrokes at all. Your scheme would probably prevent even the best password managers from working.

  • And more attacks are probably automated rather than manual, as such the entry is more likely to be similar to a password manager entering the password... – nhgrif Apr 29 '16 at 3:31
  • 2
    A password manager could always generate a random keystroke input pattern though, but that doesn't solve the issue of sandwich holders. – J Young Apr 29 '16 at 7:49
  • 21
    On top of that there is also the issue of different input devices. I bet most people type in very different speeds on their laptop, mobile phone, tablet or Xbox. – dirkk Apr 29 '16 at 11:48
  • 3
    @dirkk - they do.. everyone uses a wide variety of devices, and while this subject is interesting it's ultimately flawed due to the fact people will use different input devices for passwords. Kinda neat idea though, perhaps as a 2nd factor or something.. – John Hunt Apr 29 '16 at 13:30
  • 6
    @dirkk And then you have the people that switch to alternate layouts like Dvorak that will either get the correct password OR the correct timing but not both when using a different machine with standard layout. – David Starkey Apr 29 '16 at 14:18
38

There's some good, some bad, and some REALLY ugly in here.

The Good
It increases a passwords entropy and makes it harder to brute force

The Bad
It is based on something that can be audibly recorded and timed and needs fault tolerances meaning something only has to be close enough to render this moot

The REALLY ugly
People change over time. For a multitude of reasons(injury, age, forgetting how the pattern goes) they may no longer be able to enter it at that same exact speed and frequency or within tolerances anymore and then it actually harms a users ability to use the service

So while a cool idea and an interesting field, it's really nothing more than hard for human to maintain entropy on the password. Worse yet it's easy to recreate the pattern with machines. It will make it harder to hack without prior knowledge of the person or pattern, but it could also worsen a user's experience with your service over time and make it easier to gather local information about the password entropy.

  • 3
    but these are all similar pros/cons for any biometric, correct? – schroeder Apr 28 '16 at 21:41
  • 1
    Close. The problem is this isn't just bio-metrics, but also audio-metrics(sound patterns). Bio metrics are better there because you have to see them to record them. This just needs to be nearby for the timing pattern. – Robert Mennell Apr 28 '16 at 21:47
  • 1
    It does bring some really cool entropy to the password though, but that's easy to do without adding an extra system int the first place by just increasing the length or character set. – Robert Mennell Apr 28 '16 at 21:48
  • 12
    "Easy to intercept/replicate" and "easy to forget" is pretty much two of the worst features for a password. – Oleg V. Volkov Apr 29 '16 at 13:29
  • 5
    To add to REALLY UGLY: I often type my password slowly when it does not log in and I'm sure that I'm using the correct one, which leads me to think that I'm miss-pressing a key. – JorgeeFG May 2 '16 at 14:08
18

whether it was a viable addition to security these days

The only reason I don't think it would be viable is people log in from so many different devices these days. I can promise you there is no correlation to the rhythm I type my password with on my main work desktop and the Swype keyboard on my tablet.

  • 2
    Even laptop vs. desktop, or you use different keyboard layout (work in English, personal system in another language, or you like dvorak). – Chris H Apr 29 '16 at 8:22
  • standing in the bus with your phone vs sitting at your desk in front of the pc – miva2 Apr 29 '16 at 9:54
  • 1
    For that matter, I have different mouse/keyboard combinations for the same device (laptop). When I'm traveling, I use a mini-keyboard, or even the one that's molded into the laptop, when I'm at my desk at work, I have a different keyboard/mouse set than I do at home, etc. The timing on my keystrokes varies wildly according to that, in addition to time of day (caffeine/tired) and gawd only knows what else. Keystroke dynamics are just a fundamentally poor choice for a security feature. – HopelessN00b Apr 29 '16 at 15:49
13

Yes, it's more secure. It would make a 8 character timed password as strong as a ~9.5 characters long non-timed password.

This would be a form of keystroke dynamics. It's been an area in active research for a while - although software running on an Amiga probably predates most of it!

There's a python package for that, in case you want to experiment in a more modern language (disclaimer: I wrote it).

Some modern services actually use this technique - like Coursera, who uses it to make sure the person who is answering a test is the actual user.


Let's explore a bit of theory in order to answer your question. The usual options for human authentication are:

  • Something you know (password, pin-code)
  • Something you have (cell phone, hardware token, smart card)
  • Something you are (fingerprint, iris, gait). Usually biometrics.

Keystroke dynamics belong in the third category. Usually, good authentication systems rely on having more than one of these. When using two different systems, this is commonly known as two-factor authentication.


Usually, biometrics come with a couple of caveats:

  • They may change over time. Your typing pattern will change with the time of day, your chair and desk height, the keyboard you're using, and many other factors
  • They may be irretrievably lost. If you manage to lose a finger, you won't ever be able to authenticate.

Your design, however, is not employing a traditional biometric. You are asking the user to remember a typing pattern. This would fall in the first category (something you know), so, effectively, you can measure the amount of security it adds using entropy.

Assuming your system has two possible key press durations (which your example seems to imply), this adds one bit of entropy per character - thus it would make a 8 character timed password around as strong as a ~9.5 characters long non-timed password.


Of course, the design has flaws as well, when compared to biometric keystroke dynamics:

  • the fact that the pattern is very distinctive will make it more susceptible to an attacker with a audio recorder
  • Since the pattern is known by the user, they can be coerced into revealing it. Traditional keystroke dynamics can be used as implicit authentication.
  • "this adds one bit of entropy per character - thus it would make a 8 character timed password around as strong as a ~9.5 characters long non-timed password." This sounds wrong. One additional bit per character should give you 8 extra bits. Assuming you normally have 1.1 bits/character, you'd have ~ 8.8 + 8 = 16.8, equivalent to 15.2 characters, not 9.5. Furthermore I'd say that what counts is not the number of letters, but rather the number of intervals between letters, so it would be 7, not 8, but this is less important. – Fabio Turati May 2 '16 at 17:11
  • 2
    @FabioTurati My bad for not stating my assumptions :) I assumed a random password with a character set of length 36, which gives you 5.17 bits per character. (5.17 * 8 + 8) / 5.17 ~= 9.5. I'm not sure where you're getting the 1.1 bits/character from, it sounds very low - perhaps for a non-random numeric pin? – goncalopp May 2 '16 at 17:39
  • 1
    Ah, I see. I was thinking of typical English words, and based on this ("Shannon determined that the information content of typical written English was around 1.0 to 1.2 bits per letter") I had the value of 1.1 bits/character. But now I see what you mean. Thank you! – Fabio Turati May 2 '16 at 18:01
6

Since this basically precludes use of a password manager, which is baseline best-practices for password security, it does not improve but harms password security.

  • 3
    It should work with a lightning-speed typing password manager, but that would become the only way to login – Xen2050 Apr 29 '16 at 0:35
  • What if you use it for the password of the password manager? ;) – goncalopp Apr 29 '16 at 2:02
  • 9
    Sounds like a great way to get locked out of everything. – R.. Apr 29 '16 at 2:07
  • @R.. It's fun when that happens; you either get to crack the encryption of your password manager, or you have to remember your passwords. Fun fun fun. – wizzwizz4 May 3 '16 at 19:31
  • @wizzwizz4: With proper use of a password manager your passwords are not rememberable because you never knew/saw them to begin with. They're all long random strings. – R.. May 4 '16 at 0:50
5

It's a neat idea, and the net effect would be an increase in password entropy. For example, suppose your threshold is 1/4 second and the maximum pause is 1 second. At some point the pauses would be converted into bits, and this would effectively increase the password character set by 4X; e.g. an 80 character set would become a 320 character set. A 10 digit password with 80 possible characters would become 1 million times more difficult to brute force by implementing your idea. Another way to say that is your 10 character password would become more like 13 or 14 characters.

Practically speaking, the main benefit I see would be that it is probably easier for humans to remember the rhythm to a song combined with 10 characters than it is to remember 14 characters. But the best passwords are those that humans can't remember anyway, so it would probably be a lot simpler (for all parties involved) to just add a few more characters to your password to achieve the same increase in entropy.

  • It would likely decrease entropy by making it difficult or impossible to use a password manager. A user who has to be able to remember a password and type it consistently will not use a long or complex password. The entropy boost from recording the keyboard timing of a 10-digit password is miniscule compared to the entropy loss from encouraging shorter passwords versus the very long, very complex passwords that password managers handle with no problem. – Ed Cottrell May 3 '16 at 18:23
  • You're misunderstanding my point. People won't use password managers in such a context, and you would be actively discouraging their use. This is especially true when you tell a user they need a password x characters long, but allow it to be only y characters long (where x < y) if they type it by hand. This is not to mention the many problems others have pointed out. – Ed Cottrell May 3 '16 at 18:43
  • I don't want to get into a back-and-forth because we've both already made our points. But I believe you significantly overestimate the entropy value of the timing information and the rationality of users, while underestimating the laziness of users, the sloppiness with which users pick passwords, and the challenges of implementing such a system in a way that doesn't cause major problems. – Ed Cottrell May 3 '16 at 19:02
  • After thinking about this more, I think we can delete this comment thread except for your first comment (I will delete mine now). My response should have been simply: my answer and the original question aren't talking about the implementation, only the mathematical effect of doing this. My second paragraph agrees with you: we should be using a pw manager and why bother with the hassle for both developers and users if you can just add a few characters to the password and achieve the same result. – TTT May 3 '16 at 19:11
5

I've done a little work in this, and some related areas, and my response to the question depends on how much time you've got:

Short answer: Yes, with a but.

Simply put, as you've discovered previously, there are similarities in observed keystroke (or other behavioral biometric patterns). These can, theoretically, be used for additional security, but the false-positive and false-negative rates are still comparatively high, so usability is questionable, and there aren't any pre-built libraries that I would recommend as reliable.

Longer Answer: No, with a however.

The problem with behavioral biometrics in the context of security is that it doesn't fit with our current models. If you're given a password, it's either right, or it's wrong. If something's measuring your iris, it's a match or it isn't. There's no leeway or wiggle room, one or the other, binary authentication.

Behaviorals don't do this. Behaviors change depending on the time of day, the time of month, the weather outside. You can say "this looks like this person", but there's no cut and dry "yes/no" response, which makes them bad at traditional authentication, particularly with short sample sizes like passwords.

On the other hand, there are a lot of behavioral analytics that can be measured (network usage, keystroke, mouse usage, movement, and a wealth of others). These can be combined to give a sustained confidence indication over a prolonged period. So, for example, you could log onto your machine, and it wouldn't let you access your bank because it's not verified you yet. Do a few other things you need to, work for a while, and the algorithms return a good confidence value, and access is granted to privileged systems.

Essentially, the binary authentication routes currently in place are not well suited to behavioral biometrics, but there's a lot of promise for trust-based authentication further down the line.

4

Another reason for no: Assume your user mistypes their password occasionally. You may type it perfectly, but the rest of us have fat fingers sometimes. They will probably type it more slowly on the second attempt and screw up your metrics. This is particularly true if there's any detectable timeout/delay (rate-limiting or just a slow login server) as they wouldn't want to wait for another delay having already been annoyed by the first

1

Let's call this timed password entry.

Essentially, what you are doing is this:

  • Trying to increase the password entropy.

This has some cons, such as the fact that people change, and it might bite you back after some years.

The question is: is this method of increasing password entropy worth it? To answer this correctly, you need to first measure total entropy gained by requiring a timed password entry.

I would argue that you won't gain much entropy, because most people would generally use keyboards about similarly. So when you know that most people generally use keyboards about similarly, you will know that there isn't much entropy (or information) in knowing the timed typing.

Therefore I suggest that:

  • Timed password entries are not worth the risks.
  • If you need more entropy, just use higher quality passwords (longer with more random letters).
  • "most people would generally use keyboards about similarly" Do you have a reference for this? I would expect that people use keyboards in ways that are notably different. – Dennis Jaheruddin May 3 '16 at 9:41
  • No. It's just my observation. What I observed is that there is a few classes of keyboard usage methods. I'd imagine at most 5 classes, and it's highly likely to be distributed in a way that is not uniform. E.g. some classes have a huge user base, while other shave little. Therefore, if you measure entropy gained by those 5 non-uniformly distributed classes, it should be less entropy than just adding 2.3 bits. – caveman May 4 '16 at 14:52
1

It is a very cool idea, but if it wasn't implemented correctly as everyone else has said it wouldn't work because people change and the fault tolerance would have to be implemented correctly.

My idea for a good way for this to be implemented would be to see if the user inputs their password in the certain time pattern and if it isn't and the password is correct then you could use this information to make the request seem a bit suspicious and have other things like maybe asking the user to get a text to their phone to make sure it is really them.

The Pros: the user enters their password normally, if it is out of time then you can go to secondary measures of authentication. This would only bother the user if they type it in abnormally or if their is someone trying to get into their account.

The Cons: their could be false positives that could annoy the user trying to login, and the timings could be seen and/or recorded by someone looking over your shoulder.

1

Yes it can work, if handled properly

The benefits are clear: it is harder for someone else to log in with your password. Guessing becomes harder, and even if someone has (part of) your password, he's not done yet.

So, I will adress the concerns:

Yes you can still log in with a broken finger

Sure, the password can get 'lost' when you break your finger, but this can be remedied by making a (stronger) master password available. If you ever have circumstances that do not enable you to keep your rythem, you can always use the master password to get in. (And change the rythem if needed).

Yes you can still use multiple devices

Obviously different kinds of devices will have different rythems, but if you use them frequently, the rythem per device should be stable enough. As such, you can allow users to have multiple valid rythems.

Yes you can still use password managers

Obviously password managers could be made to submit the rythem as well as the keystrokes. Though this may be challenging, it could be very easy to just use the aforemetioned master password when logging in with the password manager.

0

Rather than have it brutally block/allow the user you could have it " learn " the user's method over a period of 10-20 logins and take the median with a slight margin of timing.

Regular login: - Password + two factor login by app / sms / email link

After a while you'll know his pattern, and can give the user the option to enable the added security, and then lower the amount of times he needs to log in with the two factor login. (presuming the same IP was used)

When the added security is active, you could then allow the user to login with just the password as long as the IP source is the same. Giving him an easier / faster login method. And when you detect the user is varying his login tap tap tap speed a lot from earlier registrations, you could ask for the two factor login again and update the list. (always take the median over 5 login attempts, eliminating the extremes)

0

I think that this would have the most potential for situations where a password is used often and the input doesn't allow a large variety of characters. An obvious example would be something like a door entry code. This also has the advantage that even if somebody is able to see the code itself over your shoulder they still have to get the rhythm right. This also allows you to get more entropy out of a very basic input device.

You could even imagine a situation where there is just one button and they rhythm is the only input, after all this is a digital version of the 'secret knock'.

If nothing else this may have some novelty value for low level security applications and may even have more serious niche for say professional musicians who would be expected to have a very accurate sense of timing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.