4 ms·

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. A

by gsoltis 15y ago

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.

Herring 15y ago
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.
- gsoltis 15y ago
  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).
  - hn12 15y ago
    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.
  - Herring 15y ago
    >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.

by gsoltis 15y ago

Herring 15y ago

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.

gsoltis 15y ago
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).
- hn12 15y ago
  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.
- Herring 15y ago
  >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.