Behavioral Profiling: The password you can't change (2015)
paul.reviews
paul.reviews
Is the "profile" updated or is it the one from the incialzation phase?
The major point of a password is authentication (that the user logging in as username Foo is actually the user they claim to be). If there’s something that you can’t change or revoke, but no one else can imitate it, I agree it’s identity, but seemingly in the good sense of that phrase (as in my family can identify me in both the naming sense, “I am @sokoloff”, and verify the authenticity of my claim “Yup, I confirm that is @sokoloff”).
I want to use different passwords for different accounts and I don't want the password to contain enough information to identify me.
That holds with biometrics too. If I have a new wart on my finger, or maybe a cut or a burn or something, can I still login with my fingerprint? If I'm logging in from a device without a camera, or in a dark place, can I still login with the facial recognition?
If I'm under a lot of stress and typing on a bubble keyboard or perhaps a touchscreen, instead of my usual buckling-spring mechanical keyboard in a relaxed setting, will your measurements of typing speed still allow me to login? What if I use a password manager that autotypes the username and password?
Any addition like that is another potential point of failure. And if it prevents legitimate use, then it's a bug.
However, it does have a place in flagging potentially suspicious activity for review. Banks, at least mine, do a great job of flagging and alerting on suspicious transactions. They've been doing that for many years. Those automated calls that say "Call back at the number printed on your card and press 1 if you authorized all four of the following transactions or 2 if you did not." have a really good success rate in my personal experience. But that doesn't prevent me from buying something or from logging in.
Behavioral profiles are useful, but not appropriate for passwords or identities.
Not sure if it got any further traction, though.
Here is the paper from USENIX Security 2012:
Neuroscience Meets Cryptography: Designing Crypto Primitives Secure Against Rubber Hose Attacks http://bojinov.org/pdfs/usenixsec2012-rubberhose.pdf
Exposing this timing data to arbitrary JS code via the DOM was a horrible oversight in the first place. I doubt any websites apart from interactive games actually need to time keystrokes. For those that do, an opt-in permission (like the camera/mic ones) would work.
http://blog.tyrannyofthemouse.com/2021/04/leaked-google-init...