3 ms·

When I first saw this post, I got excited that someone had finally addressed the side channel from 17 years ago, which gathered inter-packet timing from ssh pac

When I first saw this post, I got excited that someone had finally addressed the side channel from 17 years ago, which gathered inter-packet timing from ssh packets (and the fact that passwords are not echo'd) to a) detect when passwords were being typed, and b) use Hidden Markov Models to extract keystroke timing to try to extract the likely passwords. There have been defenses proposed over the years, but none were accepted by OpenSSH AFAICT. https://users.ece.cmu.edu/~vsekar/Teaching/Spring19/18731/reading/SideChannel_Song.pdf https://users.ece.cmu.edu/~vsekar/Teaching/Spring19/18731/re... https://www.researchgate.net/publication/2907598_Timing_Analysis_of_Keystrokes_and_Timing_Attacks_on_SSH https://www.researchgate.net/publication/2907598_Timing_Anal...

wahern 7y ago
The proper defense is to not use passwords. It's 2019, nobody should be using passwords on SSH-enabled shell accounts. Heck, I use secure tokens for authentication so this memory encryption hack is useless to me--even I don't know what my private key(s) are, nor does OpenSSH or any other software on my computers. But I appreciate that we're a long way from ubiquitous hardware-based authentication.
- gnur 7y ago
  After you are connected you might still want to enter a password (for sudo perhaps).
  - rphlx 7y ago
    The solution there is to have the app use line buffering rather than a "raw" term mode that exposes inter-char timing on the network. How widely that's followed in practice, I do not know, but one would certainly hope that sudo does it.
rphlx 7y ago
If you really cannot use keys, then one mitigation is to use copy/paste to paste the entire password instead of typing it one character at a time. That can open some copy/paste vulnerabilities e.g. in X11 where any app can then read the password until you copy something else in its place. And a network observer may still determine the password length. But it closes the inter-key timing channel that permits direct character recovery.

wahern 7y ago

The proper defense is to not use passwords. It's 2019, nobody should be using passwords on SSH-enabled shell accounts. Heck, I use secure tokens for authentication so this memory encryption hack is useless to me--even I don't know what my private key(s) are, nor does OpenSSH or any other software on my computers. But I appreciate that we're a long way from ubiquitous hardware-based authentication.

gnur 7y ago
After you are connected you might still want to enter a password (for sudo perhaps).
- rphlx 7y ago
  The solution there is to have the app use line buffering rather than a "raw" term mode that exposes inter-char timing on the network. How widely that's followed in practice, I do not know, but one would certainly hope that sudo does it.

rphlx 7y ago

If you really cannot use keys, then one mitigation is to use copy/paste to paste the entire password instead of typing it one character at a time. That can open some copy/paste vulnerabilities e.g. in X11 where any app can then read the password until you copy something else in its place. And a network observer may still determine the password length. But it closes the inter-key timing channel that permits direct character recovery.