10 ms·

Keystroke timing has been a concern for terminal I/O since the 1980s and folks were using primitive encryption with stelnet and kerberos. Most terminal applica

Keystroke timing has been a concern for terminal I/O since the 1980s and folks were using primitive encryption with stelnet and kerberos. Most terminal applications use buffered I/O for password entry, which is still an important security feature. In that mode, nothing is sent to the other end until the user presses return. A MiTM only "sees" one packet no matter what, and with padding they can't even infer the password length. For a time, there was rich pickings in applications that accepted passwords in unbuffered mode. Many of them doing it so that they could echo "*" symbols, character by character, as the user typed. That simple feature looks cool, and does give the user feedback ... but would leak the keystroke rate, which is the last thing you want on password entry. I hope we preserve buffered I/O for password entry, because it's still better than what ssh can do with some obfuscation. But it's great to see ssh add this, and will help protect content that can't be buffered, like shell and editor input.

darkclouds 3y ago
> Keystroke timing has been a concern for terminal I/O since the 1980s and folks were using primitive encryption with stelnet and kerberos. I had a visual basic AI addon in the 1990's that could work out who was typing at the keyboard from their typing pattern within a few minutes of typing, which kind of rendered the logon process mute. Today, that can applied to touchscreen logons by tying finger pressure patterns ie size and shape of finger contact with the touchscreen to a user, and when incorporating swipes or mouse movements in the desktop OS context, its possible to have a security app which can lock a system if someone is using a device and user account which is not theirs. At the very least you can log every time one's GF/missus has gone through your phone.
- archgoon 3y ago
  Spiffy! Do you remember what were you using as your model? (Btw, 'moot' not 'mute' :) )
  - darkclouds 3y ago
    I dont know, I dont think we even had that much access to tune it so to speak, this was VB4 (1991) back then, I dont think it was a VB extension but an OCX (1994) which is OLE2/ActiveX technology. I think I got it from a 3.5" disc on the front of a computer mag from memory in the UK but it was a US company that wrote it. So there might be a copy of it in the wayback machine. It was quite simple to use, so alot of their AI decisions or tuning was probably already made for us in order for it to be put out there as an addon. But I have never seen anything since for an addon, and it seemed such a good idea in the scheme of things when it comes to computer security with all the hacking that is in the press today.
- placesalt 3y ago
  > mute moot?
  - zoklet-enjoyer 3y ago
    That's the 4chan guy
    - tomrod 3y ago
      Whose username is derived from "moot".
    - 14u2c 3y ago
      Nah it's a brand of synthesizer.
      - pessimizer 3y ago
        No, the meaning of "moot" is clear. It simply means a question that at the current time has lost its relevance, or that at the current time has just become the only question that is relevant. Easy.
  - pkulak 3y ago
    Like a cow’s opinion.
- pickleberto 3y ago
  [flagged]
- deleted 3y ago
  [deleted]
eklitzke 3y ago
Password based ssh authentication should be used approximately never.
- tsbinz 3y ago
  That is not the only time you use passwords over ssh, e.g. I don't use a password to remote into my desktop from my laptop, but I do use one when using sudo on the desktop.
  - vladvasiliu 3y ago
    Is there no way to forward fido tokens? Or the GPG agent with a Yubikey. Under Windows, you can forward your smartcard over remote desktop. It's one of the few things Windows has I miss on Linux.
    - 2Gkashmiri 3y ago
      i attempt to use this and some programs recognize this and many just don't
      - vladvasiliu 3y ago
        Don't these apps just use PAM? Since the initial complaint was about sudo, I'd figure pam / polkit would handle this, and apps would call those to obtain privilege elevation.
    - ptman 3y ago
      Forwarding the ssh agent (-A) is considered insecure. Instead man ssh recommends using a jump host (-J)
      - vladvasiliu 3y ago
        I was talking about the GPG agent, so that the key on the smart card can be used to for sudo elevation on the remote host. This usually requires user interaction with the key, so just having access to the agent wouldn't do much. I don't think the ssh agent would help with this. To your point, I wonder whether that consideration holds when the private key is held on an external device, like is the case with a YubiKey. I use that setup, and I can't add the key to the ssh agent. $ ssh-add .ssh/id_yubikey_gpg.pub Error loading key ".ssh/id_yubikey_gpg.pub": error in libcrypto SSH connections work fine with that key.
pbhjpbhj 3y ago
Aside, I've noticed that the current technique of rendering a fixed number of asterisks independent of the password length is quite confusing to users -- "that's wrong, it's the wrong length", resulting in attempts to type in the "correct" password and this obviating the benefit of the stored password. Not sure how to fix that. I recall a visible hash of some form being used in the past (eg take a 2-digit hash, pair of with a smiley; I must have entered it right, it's showing me ROFL smiley), but that would aid shoulder surfed password entries, at least.
- letsdothisagain 3y ago
  I'm honestly seeing little value in asterisks with WFH and the move to passphrases. Feedback is important when you're typing a long phrase with complete precision. Plus shoulder surfing is simply not a thing when my physical security profile now involves a locked front door and a call to the police.
  - iknowstuff 3y ago
    Are you describing your experience or implying that the industry should change this because you can WFH?
    - froggit 3y ago
      The latter. They seemingly meant "I can WFH, so asterisks are meaningless to everyone. F@&# asterisks!"
  - autoexec 3y ago
    WFH also means Working From my backyard, the coffee shop around the corner, the library, a friend's house, a hotel room, etc. Even for people who only work at home while working remotely, private homes can see a lot of traffic. I wouldn't assume all screens are kept and used in totally secure environments so we should probably still stick with masked passwords and telling users not to keep passwords written on a post-it note stuck to their monitor.
gregw2 3y ago
Does anyone know any SSH clients that support line-buffering of input? I.e. where what you type doesn't get transmitted until you hit or click return/send? I had one of these clients (but for telnet) back in more active MUD gaming days but haven't seen it with the few SSH clients I've used since... but always thought that would be a good defense to SSH keystroke timing data leakage, and potentially superior to this 20ms delay approach mentioned in this article, at least for some usage scenarios. (Although now that I think about it, ideally you might want it to also transmit when someone hits tab so you could still have linux shell autocomplete...)
- howeyc 3y ago
  I would assume that doesn't work well for text editing.
- kelnos 3y ago
  That would only work if the ssh client could know exactly what was going on in the user session. Like, how would that work if I were editing a file with vim? Or even just typing a command into the shell (where I might need to backtrack and edit the command)? This doesn't seem very feasible or useful to me.
  - yencabulator 3y ago
    That's what the TTY settings are for. The program displayed controls line buffering by setting the TTY mode as it wants. https://www.linusakesson.net/programming/tty/ https://www.linusakesson.net/programming/tty/
- jesprenj 3y ago
  mosh is quite smart with this
  - gregw2 3y ago
    Not exactly what I was looking for in terms of the security side of things but perhaps more sophisticated in terms of the editing handling. Cool, thanks for the reply! Money quote from https://mosh.org/#techinfo https://mosh.org/#techinfo : Remote-shell protocols traditionally work by conveying a byte-stream from the server to the client, to be interpreted by the client's terminal. (This includes TELNET, RLOGIN, and SSH.) Mosh works differently and at a different layer. With Mosh, the server and client both maintain a snapshot of the current screen state. The problem becomes one of state-synchronization: getting the client to the most recent server-side screen as efficiently as possible. This is accomplished using a new protocol called the State Synchronization Protocol, for which Mosh is the first application. SSP runs over UDP, synchronizing the state of any object from one host to another. Datagrams are encrypted and authenticated using AES-128 in OCB3 mode. ... Roaming with SSP becomes easy: the client sends datagrams to the server with increasing sequence numbers, including a "heartbeat" at least once every three seconds. ... Instant local echo and line editing The other major benefit of working at the terminal-emulation layer is that the Mosh client is free to scribble on the local screen without lasting consequence. We use this to implement intelligent local echo. The client runs a predictive model in the background of the server's behavior, hypothesizing that each keystroke will be echoed at the cursor location and that the backspace and left- and right-arrow keys will have their traditional effect. But only when a prediction is confirmed by the server are these effects actually shown to the user. (In addition, by default predictions are only displayed on high-delay connections or during a network “glitch.”) Predictions are done in epochs: when the user does something that might alter the echo behavior — like hit ESC or carriage return or an up- or down-arrow — Mosh goes back into making background predictions until a prediction from the new batch can be confirmed as correct. Thus, unlike previous attempts at local echo with TELNET and RLOGIN, Mosh's local echo can be used everywhere, even in full-screen programs like emacs and vi.
a-dub 3y ago
i don't really type passwords into remote connected terminals anymore and haven't for some time. shrug while shoring up the existing holes is worthwhile, people should really be using keys or difficult to type passwords in 2023.
abwizz 3y ago
> Most terminal applications use buffered I/O for password entry does the existance of this patch implicate that openssh does not behave that way?
alickz 3y ago
so that's why my terminal doesn't show "*" as i type my password? tripped me up the first time i used a shell. interesting to see why

darkclouds 3y ago

> Keystroke timing has been a concern for terminal I/O since the 1980s and folks were using primitive encryption with stelnet and kerberos. I had a visual basic AI addon in the 1990's that could work out who was typing at the keyboard from their typing pattern within a few minutes of typing, which kind of rendered the logon process mute. Today, that can applied to touchscreen logons by tying finger pressure patterns ie size and shape of finger contact with the touchscreen to a user, and when incorporating swipes or mouse movements in the desktop OS context, its possible to have a security app which can lock a system if someone is using a device and user account which is not theirs. At the very least you can log every time one's GF/missus has gone through your phone.

archgoon 3y ago
Spiffy! Do you remember what were you using as your model? (Btw, 'moot' not 'mute' :) )
- darkclouds 3y ago
  I dont know, I dont think we even had that much access to tune it so to speak, this was VB4 (1991) back then, I dont think it was a VB extension but an OCX (1994) which is OLE2/ActiveX technology. I think I got it from a 3.5" disc on the front of a computer mag from memory in the UK but it was a US company that wrote it. So there might be a copy of it in the wayback machine. It was quite simple to use, so alot of their AI decisions or tuning was probably already made for us in order for it to be put out there as an addon. But I have never seen anything since for an addon, and it seemed such a good idea in the scheme of things when it comes to computer security with all the hacking that is in the press today.
placesalt 3y ago
> mute moot?
- zoklet-enjoyer 3y ago
  That's the 4chan guy
  - tomrod 3y ago
    Whose username is derived from "moot".
  - 14u2c 3y ago
    Nah it's a brand of synthesizer.
    - pessimizer 3y ago
      No, the meaning of "moot" is clear. It simply means a question that at the current time has lost its relevance, or that at the current time has just become the only question that is relevant. Easy.
- pkulak 3y ago
  Like a cow’s opinion.
pickleberto 3y ago
[flagged]
deleted 3y ago
[deleted]

eklitzke 3y ago

Password based ssh authentication should be used approximately never.

tsbinz 3y ago
That is not the only time you use passwords over ssh, e.g. I don't use a password to remote into my desktop from my laptop, but I do use one when using sudo on the desktop.
- vladvasiliu 3y ago
  Is there no way to forward fido tokens? Or the GPG agent with a Yubikey. Under Windows, you can forward your smartcard over remote desktop. It's one of the few things Windows has I miss on Linux.
  - 2Gkashmiri 3y ago
    i attempt to use this and some programs recognize this and many just don't
    - vladvasiliu 3y ago
      Don't these apps just use PAM? Since the initial complaint was about sudo, I'd figure pam / polkit would handle this, and apps would call those to obtain privilege elevation.
  - ptman 3y ago
    Forwarding the ssh agent (-A) is considered insecure. Instead man ssh recommends using a jump host (-J)
    - vladvasiliu 3y ago
      I was talking about the GPG agent, so that the key on the smart card can be used to for sudo elevation on the remote host. This usually requires user interaction with the key, so just having access to the agent wouldn't do much. I don't think the ssh agent would help with this. To your point, I wonder whether that consideration holds when the private key is held on an external device, like is the case with a YubiKey. I use that setup, and I can't add the key to the ssh agent. $ ssh-add .ssh/id_yubikey_gpg.pub Error loading key ".ssh/id_yubikey_gpg.pub": error in libcrypto SSH connections work fine with that key.

pbhjpbhj 3y ago

Aside, I've noticed that the current technique of rendering a fixed number of asterisks independent of the password length is quite confusing to users -- "that's wrong, it's the wrong length", resulting in attempts to type in the "correct" password and this obviating the benefit of the stored password. Not sure how to fix that. I recall a visible hash of some form being used in the past (eg take a 2-digit hash, pair of with a smiley; I must have entered it right, it's showing me ROFL smiley), but that would aid shoulder surfed password entries, at least.

letsdothisagain 3y ago
I'm honestly seeing little value in asterisks with WFH and the move to passphrases. Feedback is important when you're typing a long phrase with complete precision. Plus shoulder surfing is simply not a thing when my physical security profile now involves a locked front door and a call to the police.
- iknowstuff 3y ago
  Are you describing your experience or implying that the industry should change this because you can WFH?
  - froggit 3y ago
    The latter. They seemingly meant "I can WFH, so asterisks are meaningless to everyone. F@&# asterisks!"
- autoexec 3y ago
  WFH also means Working From my backyard, the coffee shop around the corner, the library, a friend's house, a hotel room, etc. Even for people who only work at home while working remotely, private homes can see a lot of traffic. I wouldn't assume all screens are kept and used in totally secure environments so we should probably still stick with masked passwords and telling users not to keep passwords written on a post-it note stuck to their monitor.

gregw2 3y ago

Does anyone know any SSH clients that support line-buffering of input? I.e. where what you type doesn't get transmitted until you hit or click return/send? I had one of these clients (but for telnet) back in more active MUD gaming days but haven't seen it with the few SSH clients I've used since... but always thought that would be a good defense to SSH keystroke timing data leakage, and potentially superior to this 20ms delay approach mentioned in this article, at least for some usage scenarios. (Although now that I think about it, ideally you might want it to also transmit when someone hits tab so you could still have linux shell autocomplete...)

howeyc 3y ago
I would assume that doesn't work well for text editing.
kelnos 3y ago
That would only work if the ssh client could know exactly what was going on in the user session. Like, how would that work if I were editing a file with vim? Or even just typing a command into the shell (where I might need to backtrack and edit the command)? This doesn't seem very feasible or useful to me.
- yencabulator 3y ago
  That's what the TTY settings are for. The program displayed controls line buffering by setting the TTY mode as it wants. https://www.linusakesson.net/programming/tty/ https://www.linusakesson.net/programming/tty/
jesprenj 3y ago
mosh is quite smart with this
- gregw2 3y ago
  Not exactly what I was looking for in terms of the security side of things but perhaps more sophisticated in terms of the editing handling. Cool, thanks for the reply! Money quote from https://mosh.org/#techinfo https://mosh.org/#techinfo : Remote-shell protocols traditionally work by conveying a byte-stream from the server to the client, to be interpreted by the client's terminal. (This includes TELNET, RLOGIN, and SSH.) Mosh works differently and at a different layer. With Mosh, the server and client both maintain a snapshot of the current screen state. The problem becomes one of state-synchronization: getting the client to the most recent server-side screen as efficiently as possible. This is accomplished using a new protocol called the State Synchronization Protocol, for which Mosh is the first application. SSP runs over UDP, synchronizing the state of any object from one host to another. Datagrams are encrypted and authenticated using AES-128 in OCB3 mode. ... Roaming with SSP becomes easy: the client sends datagrams to the server with increasing sequence numbers, including a "heartbeat" at least once every three seconds. ... Instant local echo and line editing The other major benefit of working at the terminal-emulation layer is that the Mosh client is free to scribble on the local screen without lasting consequence. We use this to implement intelligent local echo. The client runs a predictive model in the background of the server's behavior, hypothesizing that each keystroke will be echoed at the cursor location and that the backspace and left- and right-arrow keys will have their traditional effect. But only when a prediction is confirmed by the server are these effects actually shown to the user. (In addition, by default predictions are only displayed on high-delay connections or during a network “glitch.”) Predictions are done in epochs: when the user does something that might alter the echo behavior — like hit ESC or carriage return or an up- or down-arrow — Mosh goes back into making background predictions until a prediction from the new batch can be confirmed as correct. Thus, unlike previous attempts at local echo with TELNET and RLOGIN, Mosh's local echo can be used everywhere, even in full-screen programs like emacs and vi.

a-dub 3y ago

i don't really type passwords into remote connected terminals anymore and haven't for some time. shrug while shoring up the existing holes is worthwhile, people should really be using keys or difficult to type passwords in 2023.

abwizz 3y ago

> Most terminal applications use buffered I/O for password entry does the existance of this patch implicate that openssh does not behave that way?

alickz 3y ago

so that's why my terminal doesn't show "*" as i type my password? tripped me up the first time i used a shell. interesting to see why