A while ago I posted a comment about why modern computers don’t realise a small typo in a password and just let me in.
Now that passwords are getting more complicated, a good thing, it also means they can be harder to type efficiently.
In fact, keyboard layouts were defined around the words we type, initially to prevent type bars on early typewriters jamming when frequent letter pairs were used.
But when using a complex password, and not a passphrase, the flow isn’t as natural.
A 50 character password might be
I realise this is a bit longer than most people’s passwords, but it even a remembered 12 character password can still be cumbersome.
So that fleeting comment got me thinking. Could we recognise the behaviour patterns of entering a password, and together with what was actually typed, determine a confidence score to allow the user through.
I realised there are two behaviour patterns I could analyse that wouldn’t require any additional equipment.
Password patterns
We are used to the pattern unlock codes make on phones, pin numbers and telephone numbers we enter onto keypads, and also the pattern we use when typing our own names and email addresses.
Passwords also present a pattern, the layout of the keys typed in order leaving a zig-zag dot-to-dot behind.
When we make a typo it is generally by pressing a key next to the target. This small error does make a difference in the pattern generated, but only a small deviation. The main pattern resembles its normal form.
Rhythm patterns.
Like entering my email address, typing a password creates not just a pattern but a rhythm. It has its own signature sound, made up of the keys being pressed, how long they’re held, and the pauses between them, with the Enter key being the final note.
Capturing the data.
Most people think we only capture what’s in a field when the form is submitted. But we can capture enough detail to record the ‘pattern’ of the text being entered.
We are able to capture the dwell time of a key being pressed, how long it was pressed for, and also measure the ‘flight time’ as the duration between key presses.
Once a user is familiar with what they are entering, it becomes more natural, using a bit of muscle memory to enter characters in the same order each time.
Now the idea of this experiment is to see if we can spot and allow small mistakes.
Since we understand that mistakes are normally neighbour keys being pressed instead, the rhythm pattern of dwell and flight would vary only a small amount.
So by comparing the rhythm pattern with the known good pattern, we can get a confidence score that the same person entered the characters.
The password pattern is simply the shape the password makes when drawn on the keyboard, but the big problem here is that if we know the shape, we can easily guess the password.
To account for the keyboard layout, we use a reference point, the first key pressed, and then map movement from that location - and to make it even less obvious we use the angle and distance to each key.
For example, the pattern of awsd is the same as jikl and also bhnm.
If a user makes a mistake in this pattern, it will be noticeable, but also that the mistaken key should be neighbourly to the one it should have been, so change is small, but still enough to give us a confidence score.
Authentication.
This now gives us three pieces of information we can use to authenticate the user, the password, the rhythm and the password pattern.
The password would take priority, if this is entered correctly then we can authenticate the user.
If the password match fails (since we are sending a hash and wouldn’t know how much out it is) we can look at the next two pieces of data.
If rhythm result is a high confidence factor and the pattern has a one mistake, so again a high confidence score, then we can allow the user to be authenticated.
By using a scale of the confidence score, and weighting one more than the other we can adapt the authenticator to pass them through (it could have been a typo), request further authentication (2FA) or reject them.
Continuous learning.
The one thing we need to be sure to do is learn how the user adapts over time. The more muscle memory they build, the fast they will become at entering it.
So upon each full password match, we submit the rhythm and pattern captures to update the known result.
Sharing patterns securely
To share the patterns securely so they can be checked we need a way to normalise and encode the result.
For this experiment I have used a routine that generates an image ‘mask’ for each pattern. That mask is then used to represent a layer in a RGB image.
Applying to Gaussian blur to the image helps with obfuscation, whilst still allowing the matching analysis to be done.
The two patterns give us two layers of the final image. A third layer could be a random layer helping produce a final ‘password fog’.
I did look into other methods of sharing the data, but opted for this one in this experiment as it helps explain the concept being tested.
Results.
From my testing it seems that user behaviours can be used to help determine a confidence score as to whether a simple typo was made when entering the password.
The gathering and normalisation of the data can be incorporated into the client side, whilst the verification against the known good pattern is still performed at the authenticator end.
The password is already passed as a hash, but a secure method should be introduced to pass the behaviour patterns.
This may not be a revolutionary idea, or one that gets adopted. But it did get me thinking: what behaviours are already being learned from us as we use our devices every day? Some “Are you a robot?” checks already look beyond whether we click the box and consider how we move the pointer and interact with the page.
No comments yet