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.
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.
I've seen a GUI password input field that mutated an abstract line drawing on every keypress. Think random cross-hatching over the whole input field where the lines are nudged a little on every press.
(Not that that's necessarily a good idea, it still gives away timing/length information to e.g. cameras.)
At IBM someone made something called fetchnotes that worked like fetchmail, but worked with mail and calendar, made me able to get away with minimal usage of notes.
I think it was to provide an indication that the password was correct at a glance. (IIRC the number of dots in the password field was also generated, so it didn't necessarily match the number of chars)
The image was essentially a simple checksum. Each user would eventually memorise which icon was "theirs".
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.
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.
And now employees simply leave their laptop open with the SSH window up while getting their coffee because it's now so annoying to close the lid and correctly type the password.
> I would hope people in high leverage job roles would just avoid such behavior.
I used to hope that as well. Then I met people and lost that hope. It's truly impressive how much stupid shit gets pulled by people that "should know better."
Unlocking the password manager means I need to type a master password in while in a public place. Feels higher risk when it is an unimportant website but potentially gives access to all websites. Still better than the passwords being accessible on disk but having individual passwords would reduce the impact of any password leak.
I have this InputStick USB [1] dohicky that I keep with my keys shows up as a generic USB keyboard when plugged in but is also an encrypted Bluetooth dongle (part of pairing allows you to configure a shared encryption key so that only devices that know the key can use the stick, and only sticks with the key are recognized by the client apps). There's a plugin to Keepass2Android that I use to type passwords from my phone. I use that to unlock my password manager (using a giant untypable passphrase). So entering mosterous passphrases is very easy... bot only if you can unlock my phone and use biometrics to open Keepass2Android.
It really is dumb that phones can just generically play USB HID (without running custom kernels)
It's every two weeks. If your threat model involves being spied on over the shoulder for your master password while in a cafe you "just" need to ensure you enter your password in a safe location every two weeks.
What if you're demonstrating a problem with a login screen? And yes, I've had to do exactly that more than once.
I wouldn't do it with a particularly sensitive password (online banking etc) but there are enough passwords I use regularly for work purposes where it wouldn't be a significant risk for others to watch me type it in, certainly if the characters aren't revealed at all while typing. Though having password fields be able to detect your screen is being shared automatically and obscure what pixels are relayed would be nice.
They're typically passwords that are only for testing accounts anyway, and that are known to the team members I'm sharing with.
But...it's easy to slip up now and then and forget you're actually putting in a password while screen sharing that it's probably best not to have your co-workers know! Obviously the worst is your actual O/S password, as knowing that could potentially allow a co-worker access to other passwords that are quite sensitive, but I'm not sure it's even possible to screen share your O/S login screen - probably shouldn't be! It is a good argument for not re-using that password for any browser-based logins, but SSO policies tend to make that impossible unfortunately. Mind you I use a pin for my O/S login screen, whereas for browser-based logins you can't.
Sadly I think security systems will have to accommodate the possibility that someone else can see your screen. And hope that they can't see your keyboard.
We used Notes at work until a few years ago and it still had it IIRC. I never stopped to think about why the pictures changed, that's interesting. Another annoying decision is that they prevented pasting passwords, which is very inconvenient when using a password manager. I ended up having to use one that simulated keystrokes.
The browser could use a different rendering convention for autopopulated passwords. For instance, it could render a solid black bar (no characters for the user to count) or maybe the phrase "autofilled", perhaps with a strange background color / rendering convention.
> 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.
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.
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.
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.
Actually this is something that is relevant to my interests.
I prefer to have sudo ask for a password when I'm physically in front of the machine, but not if it's a remote session (e.g. SSH from my laptop to my desktop).
Maybe the SSH agent on the client can re-authenticate to the server when requested?
Note that this is a bad idea from the security standpoint, as it requires SSH agent forwarding. Which means that, if the remote server is compromised, the attacker can use your SSH agent to log into other servers as you.
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
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.
FWIW, you can probably configure sudo to use something other than passwords. On a Mac you can use the fingerprint reader for example, it's just disabled by default.
And your terminal may come with a password manager too, which would be unlocked with whatever means.
Again, on a Mac with iTerm you can do this with a fingerprint.
Same way you'd get the password? It's either a physical or virtual server you more or less control, in which case the siblings' answers apply. Otherwise, it's probably some kind of image or something someone else controls, in which case bake in or send them your public key or certificate (if you've got colleagues in the same situation as yourself).
The password needs to be generated somehow, right? Assuming you don't you use a pre-baked password that repeats across machines, you could replace the password generation and retrieval with deploying a public key instead.
The remote system must generate its own SSH private key; you could use that opportunity to deploy the authorized keys before sealing the system as read-only.
No, it's assuming a device running a ssh daemon with something mounted rw or user-modifiable[0] that can hold an authorized_keys file. A NetBSD embedded board that configures sshd with `AuthorizedKeysFile /sdcard/config/authorized_keys` would be fine, for instance.
[0] For example, you could let the user write their key to an SD card and then mount it ro on the device.
"One time, on first use, where absolutely necessary, and changing password immediately afterwards" seems a reasonable interpretation of "approximately never".
I don't know. I come across old AP/routers where I've forgotten the login credentials and find myself hard resetting them with some regularly, one that's above "approximately never" anyway.
I'm presuming the hard reset is to a factory-assigned password.
Is that uniform across all devices, or device-specific?
Practice I've seen for some years now is to have a label on the device with admin/root password, which is presumably neither uniform across devices nor trivially-determinable from device characteristics (e.g., MAC address, sequential serial numbers, etc.).
I'd still consider that practice reasonably tolerable, though you should be keeping better tabs on assets and credentials.
Any device where you don't control the initial firmware,
and the firmware doesn't support ssh keys. AP/Routers (consumer and commercial and industrial grade), Shared hosting with ssh but limited features (eg GoDaddy)...
For physical devices, you can usually connect them via a dedicated Ethernet cable right to your laptop, and set the initial password. They likely don't have the right network settings anyway to drop them right into the bigger LAN.
Otherwise I think you just prepare a certificate ahead of time, and scp it during the first connection, then immediately disable password-based access, or at least change the password. Any passive eavesdropping still needs to defeat the encryption somehow (no feasible ways are known now), even having seen the initial exchange.
If you have an active MITM attack, all bets are off, because the attacker could even grab the image with the pre-baked key you're sending, and copy or change the key. If this is not possible, then the pre-baked key would help. If your security is really important, don't use ther cheap GoDaddy's offerings with limited SSH.
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...)
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)?
That's more a choice a current-day shell etc does for you, wanting to control the editing experience. Run `cat` and it'll switch to line buffered mode, note how your arrow keys just input line noise, and watch the cat process with ptrace if you want to confirm it really receives the whole line in one read syscall.
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!
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.
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.