Hacker News new | past | comments | ask | show | jobs | submit login

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.


Oh yes, that could be it! Employer made me run Windows in a VM to read corporate email.

My memory doesn't match videos I can find online of it, but that could be version differences.


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.


Yes. Wasn't it to make it harder spoof a password prompt with a static image popping up?


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".


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.


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.

>USB Rubber Ducky has entered the chat


If they can see the screen wouldn’t they be better off just looking at the keyboard to directly observe what’s being typed?


> the coffee shop around the corner

I would hope people in high leverage job roles would just avoid such behavior.


> 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."


Plenty of value in confirming that you are hitting each key exactly once.


Why not just mutate a specific fixed-length line with every keypress?


You've never typed a password in while screen sharing?


I don't type passwords. My password manager fills them for me, or I paste them.


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)

[1] http://inputstick.com/

[2] http://inputstick.com/kp2a-plugin/


1password uses biometrics on my 7 year old MacBook Pro, so even if I'm out and about I still don't need to type it.


1p works great on my mac but still asks for a password from time to time, I'm not sure of the exact mechanic.

OTOH even Chrome's password manager now integrates with the Mac fingerprint auth.


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.


Oh god no, absolutely not. Always stop sharing for the duration of the password entry.


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.


Why use a good password while testing your login screen? I use "iamroot" and "password".


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.


I'm going to suggest that is correct and also unusual behavior.


Are you describing your experience or implying that the industry should change this because you can WFH?


The latter. They seemingly meant "I can WFH, so asterisks are meaningless to everyone. F@&# asterisks!"


> 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


Nah it's a brand of synthesizer.


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.


Whose username is derived from "moot".


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.


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?


> Maybe the SSH agent on the client can re-authenticate to the server when requested?

There is a PAM module that does this: https://github.com/jbeverly/pam_ssh_agent_auth

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.


The local agent can ask the user to approve/deny signing requests.


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.


Forwarding the ssh agent (-A) is considered insecure. Instead man ssh recommends using a jump host (-J)


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.


i attempt to use this and some programs recognize this and many just don't


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.


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).


Getting a password does not require modifying the system. Injecting a public key does.


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.


You can commonly deploy the device/server with the client's public key.


What if it's mass produced and sold in a store?


That's assuming the device runs GNU/Linux with / mounted rw. But not everything is a laptop or a desktop.


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.


So what do you do when the device has no long-term storage like an SD card?


Such a device is then simply not suitable for situations where the issues with SSH password authentication become relevant.


What kind of device runs sshd but has no persistent storage?


"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.


It could be totally fine if you disable WiFi and connect physically. At least the first time for setup.


I'd use a base image with a baked-in SSH certificate allowed.

Fairly trivial to make, at least with NixOS.


This hinges on this being either a VM or some hardware you've set up yourself.


what other situation would you be in?


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.


Let's say you bought a router and now you want to log into it.


Then you connect physically and do whatever is necessary to prepare that router for your intended use.


Connect to what? It only has an ethetnet jack.


Are you being intentionally difficult or have you just never bought and set up a router?


Your laptop, for instance.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: