Comment by colmmacc
2 years ago
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.)
I remember seeing this in Lotus Notes. Never saw it before that, or since.
4 replies →
xsecurelock[https://github.com/google/xsecurelock] has a few variants on this.
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.
5 replies →
Plenty of value in confirming that you are hitting each key exactly once.
1 reply →
You've never typed a password in while screen sharing?
12 replies →
Are you describing your experience or implying that the industry should change this because you can WFH?
1 reply →
> I'm honestly seeing little value in asterisks
They're essential ! How else would we encourage the average user to use as short and and as simple a password as they can get away with ?
Lotus Notes used to have that. (Might still do?)
https://security.stackexchange.com/questions/41247/changing-...
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.
I’ve seen some programs render three asterisks per key stroke. Defers human shoulder surfers from seeing the length of your password.
I think simplest and safest solution would be a shape that rotates at random interval for each key stroke.
Depends what problem you want to solve. Did keyboard register my press? vs did I type the same thing as last time.? have some different constraints.
The login fractal - a shape that is infinitely recurring, starts at a random place, and indicates entry with "zooming".
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.
What about : "You are typing..." like in IM apps
> 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.
> mute
moot?
Like a cow’s opinion.
That's the 4chan guy
3 replies →
Spiffy! Do you remember what were you using as your model?
(Btw, 'moot' not 'mute' :) )
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.
[flagged]
Password based ssh authentication should be used approximately never.
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?
2 replies →
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.
4 replies →
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.
That's not what the parent is talking about.
They're specifically refering to password authentication to make the ssh connection.
we're not necessarily talking about ssh authentication. Wouldn't that send the entire password as a single packet, anyway?
correct - this is for the post-auth session and not the authentication phase
How would you log in for the first time into a headless device?
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).
3 replies →
You can commonly deploy the device/server with the client's public key.
11 replies →
I'd use a base image with a baked-in SSH certificate allowed.
Fairly trivial to make, at least with NixOS.
9 replies →
[dead]
This is naive in the extreme. There are many scenarios where passwords are needed, for bootstrapping, a disgruntled admin leaving, etc.
There is a role for a common secret in a secure ecosystem (password, passkey)
That common secret is usually an ssh key which is held somewhere secure hopefully with auditable access.
For bootstrapping you can bake a bootstrapping key into your installer which is removed after the system is configured.
This is completely irrelevant to password based SSH authentication. The timing obfuscation is for the session _after_ authentication.
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)?
This doesn't seem very feasible or useful to me.
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/
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.
mosh is quite smart with this
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 :
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.
I would assume that doesn't work well for text editing.
> Most terminal applications use buffered I/O for password entry
does the existance of this patch implicate that openssh does not behave that way?
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.
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