Hacker News Reader

Comment by gsoltis | Hacker News Reader

Also, this suffers from the same issue as many (all?) biometric authentication systems: revocation support.

Say someone hacks the db where my particular typing style signature is stored. Now they can skip the typing and send the signal my keyboard would have sent and authenticate as me to whatever service was using that db.

You can push the problem into hardware (authenticate the keyboard as well) but that's just making the same mistake twice (once the keyboard gets hacked...).

Part of a good authentication system is being able to change the locks on the door when someone loses a key, which is why biometric data is particularly unsuited for the purpose.

View on HN

Or, what if the attacker set up a website (say, a forum) and enticed someone to visit it and type something, and the site used javascript to log their typing patterns?

Perhaps if it relied on strength of hitting the keys, this would be harder, though some of this data might be retrievable from an accelerometre.

I wonder if that could handle changes in typing style. I've had finger injuries where I was deliberately typing softly with one or more fingers. Would I still be able to log in?

>send the signal my keyboard would have sent

There's a chance they can make that a non-trivial problem, like recovering plaintext given a hash.

Sure, they can absolutely make it non-trivial, but for this to be effective, it needs to be a guarantee. All it takes is one of these keyboards being cracked. Add to that the fact that the keyboards would have to be ubiquitous, and you're virtually guaranteeing that an attacker has direct access to the hardware. You then have one of the most challenging scenarios to defend against.

I didn't mean a hardware problem. I'm thinking of the "typing style signature" like a hash. Even if it's stolen, it shouldn't be easy to create a stream of keys that 'hash to' that signature.

Unless I'm misunderstanding, this is similar to what is currently recommended for storing passwords. Don't store the plaintext, store a hash instead (everyone's hash is salted, using a secure algorithm, right?), perform the same calculation on the input and compare (everyone's doing constant time comparisons, right?).

The problem is, someone out there isn't doing at least one of the above suggestions (or others that I've forgotten), or someone will intercept the original input while it's in flight (no one uses unencrypted connections on open public wifi, right?) or make use of some other arbitrary way that passwords can currently get stolen. And once they get that original digital representation of your typing style, you're done. That method will never be secure for you again for any service, unless you spend the time to change your typing style (and remember your new style should not be at all predictable to someone who knows your old style).

I'll say that, absolutely: databases should NOT store authentication information, but only salted hashes.

It's an equal certainty that there'll be implementations around for as long as humans remain that stupidly include un-hashed authentication data.

>someone will intercept the original input

It might be possible to have the server randomly choose what text to test your style on. That would also solve the secure storage. But it's a very hard problem.

Reply on news.ycombinator.com