Keystroke timing obfuscation added to ssh(1)
undeadly.org
undeadly.org
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.
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.
(Not that that's necessarily a good idea, it still gives away timing/length information to e.g. cameras.)
My memory doesn't match videos I can find online of it, but that could be version differences.
The image was essentially a simple checksum. Each user would eventually memorise which icon was "theirs".
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.
>USB Rubber Ducky has entered the chat
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."
It really is dumb that phones can just generically play USB HID (without running custom kernels)
OTOH even Chrome's password manager now integrates with the Mac fingerprint auth.
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 ?
https://security.stackexchange.com/questions/41247/changing-...
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.
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.
moot?
(Btw, 'moot' not 'mute' :) )
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.
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?
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.
Under Windows, you can forward your smartcard over remote desktop. It's one of the few things Windows has I miss on Linux.
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
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.
They're specifically refering to password authentication to make the ssh connection.
[0] For example, you could let the user write their key to an SD card and then mount it ro on the device.
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.
Fairly trivial to make, at least with NixOS.
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.
There is a role for a common secret in a secure ecosystem (password, passkey)
For bootstrapping you can bake a bootstrapping key into your installer which is removed after the system is configured.
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...)
This doesn't seem very feasible or useful to me.
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.
does the existance of this patch implicate that openssh does not behave that way?
while shoring up the existing holes is worthwhile, people should really be using keys or difficult to type passwords in 2023.
tripped me up the first time i used a shell. interesting to see why
https://en.wikipedia.org/wiki/Blue_Team_(bridge)#Cheating_an...
https://en.wikipedia.org/wiki/Fantoni_and_Nunes_cheating_sca...
https://en.wikipedia.org/wiki/Fisher_and_Schwartz_cheating_s...
And those are the ones we know about. :)
As far as actually using bridge in a job interview once. I did. In bridge there's a rule where if your partner gives you a hint not via the bidding, you must take the opposite approach if logically possible. It is called "Active Ethics". I had an interviewer try to lead me by the nose to the answer way too hard, in a debugging interview. So I'd stop and check EVERYTHING I could think of first before doing what he said. I told him I was doing it after the interview, and to look up active ethics if he needed a further explanation.
Got the job.
And sometimes the hint can be a trick! I recently did an interview where the interviewer asked if I should use a shortcut to compare two strings, one that assumed there's only one way to normalize a string. I almost fell for it, but then I hesitated and mentioned that I was concerned about some languages where that assumption wouldn't hold. They agreed and were happy that I chose the safer approach.
This guy was doing the latter, and it was meant to be an interview to test raw debugging/diagnostic skills. If I just followed the breadcrumbs, I'd show no real skill.
In a coding interview, I'd follow the hints.
In this interview I wasn't concerned about that. If you are looking to see if someone understands Linux by testing diagnostic skill, if they are coming up with 3-4 different failures to check for every step... They are doing their job.
Which if you are doing real diagnostics is often 100% the wrong answer.
I double check other people's work, and make sure that everything is right. Because one small misstep can result in not diagnosing an issue correctly.
Listen to what the user reports as the issue.... not the cause. Always work from the symptoms to the problem.
E.g. in an algorithms interview they get stuck on an unrelated python issue (many people interview in python but don't use it day to day), or in a system design interview they get stuck on designing extra-credit subsystem C when they haven't finished subsystems A and B.
If they aren't getting it after a couple hints, I'll just tell them the answer or tell them to come back to it later.
Anyway, I would be very careful if you aren't going where the interviewer is pointing you. If you think it's a trick or you want to practice Active Ethics, then I would call that out in the moment since you might be messing up the flow of the interview at best and come off as hard to work with at worst.
In all situations, judgment is required.
I still want to learn to play at a reasonable level though, I'd rather waste my time on bridge than chess. But it needs to be home games, and there's no way I'm going to find the partners when spades and bid whist are out there and easy to learn.
It has problems. Cheating is a huge issue, as is sportsmanship. If you know bridge. I used to play precision with an 11-13 1NT. When people saw our convention card, they'd often ask to swap tables with other teammates. (Clearly not legal.)
When I was playing on a team where all 4 of us played the same convention card those people made me laugh so hard.
Cheaters will cheat. I played clean, I had fun. I haven't had time to play for a while. But man, bridge is a funny little world.
IANABridgePlayer, clearly.
I've been in the situation in game a few times. Thankfully, my decisions were pretty cut and dry.
You don't have to do non-obvious things. If you are going to accept any invitation to game... You are going to accept even if partner looks happy, what I wouldn't do is throw out a slam exploring bid if I was on the fence about it.
If I was absolute top of range... I'd go ahead and make the bid. Because there is nothing that would change based on partner's actions.
This is like saying a catcher can't signal to a pitcher.
Information-passing is a human skill that adds a dimension to the game. Let the best win.
Initially learning the game it was like “oh wow, that feature of the game has some really cool implications! This is amazing!” but then reading about how real bridge tournaments run, yeah, they crafted the rules to remove every single one of those cool implications.
[EDIT] to be fair, the basic rules would also result in a terrible game as soon as people got too good at exploiting them. I just think they’ve managed to find another way to ruin the game while keeping it technically playable.
HUMs also tend to end up being very destructive to the opponents, because they really don't understand the full implications of the bid. And may not have discussed how to bid over it. Heck I've run into this with people playing over a strong club system, and they haven't discussed what 2C means.
In the end... many games end up with a few rules to make them interesting. I will not defend the ACBL here, I think the WBC is pretty much on the mark last I watched.
Nah. You choose the game that you prefer. You can play the game where you cheat all the time, but don't play it with people who like bridge without asking them first.
There is this thing called "Bridge Judgement" that you are allowed to use.
Just because your hand has 10 HCP... but has 13 spades... doesn't mean you will pass. You'll bid your 7 Spades and call it a day.
Bridge has many shades of grey. It is learning how to dance them correctly that is hard.
It’s like if baseball couldn’t change field size or mound height or whatever and just had to add lots of rules about how you aren’t allowed to throw too fast or hit too far et c., but kept the physical reality of the game the same.
>This weakness was outlined in a 2001 paper entitled Timing analysis of keystrokes and timing attacks on SSH" [PDF] which looked specifically at the timing-based attack:
>In this paper we study users' keyboard dynamics and show that the timing information of keystrokes does leak information about the key sequences typed. Through more detailed analysis we show that the timing information leaks about 1 bit of information about the content per keystroke pair. Because the entropy of passwords is only 4-8 bits per character, this 1 bit per keystroke pair information can reveal significant information about the content typed.
I thought this was fixed a long time ago and I thought there was a fix pushed around the 2012 time period. I'm totally shocked this has not been previously address.
same same
i rekon there is more going on
I am the king of typos and misspelling.
But let's be honest rubber hose cryptography is the real way to get things done.
> Users pay a fee in NYM to send their data through the mixnet.
[1]: https://warp.dev
This is why mosh can have better behaviour than pure SSH over high latency connections. However this feature isn’t going to apply to mosh.
Perhaps some very specific example of a security feature (such as protecting against timing attacks) could be protected against in a new tool, and not in the older more standard one. But it seems far more likely that many other security features would get forgotten in the newer tool, and by adding "AI" so many more attack vectors would be added.
It's honestly hard to even believe in the privacy claims of warp. Almost all NLP tools in today's age seem to fall towards cloud solutions, which almost immediately makes that likelihood of privacy close to nil.
do you have any sources for that?
I've only seen this mentioned from research results recently but no real world exploitation reports.
https://www.bleepingcomputer.com/news/security/new-acoustic-...
I got to 90% accuracy extremely quickly. The "guessed" keystrokes had errors but they were close enough to tell exactly what I was typing.
If I could do that as an amateur in a few hours of coding with no advanced signal processing and with the first SVM architecture I tried, it must be relatively easy to learn / classify.
It's quite good at decoding my own typing, although I am a quite aggressive typist and that may help. I haven't tried it on others, though (honest, officer).
From that discussion it sounds like you need to train on data captured from the actual target. Same physical keyboard in the same physical space with the same typer.
Pretty wild despite those specific conditions. Very interested to know if people have actually been attacked in the wild with this and if the attackers were able to generalize it down to just make and model of a keyboard, or if they could gather enough data from a stream.
http://www.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf [2001]
The addition of ML has greatly improved the accuracy of audio decoding - use a silent keyboard in any insecure physical locale.
https://arstechnica.com/gadgets/2023/08/type-softly-research...
For example, since users tend to type their passwords quicker than other things, you could see how many keystrokes were sent in a burst and guess the user's password length when they sudo something.
In this specific paper's use case, it's not a security threat, but you can definitely cast it as information leakage.
https://www.usenix.org/legacy/events/sec01/full_papers/song/...
> ...by sending interactive traffic at fixed intervals (default: every 20ms) when there is only a small amount of data being sent...
It took me a second, but I'm pretty sure the comment above is referring to latency in the user experience; namely, the delay between a keypress and perceived result. [1]
FWIW, tools like Mosh [2] go a long way towards reducing perceived latency. Mosh displays the user keypress as soon as it is registered locally (which happens without a perceptable delay). To indicate that it has not round-tripped, the character is shown in a washed-out color, last I checked. (Or maybe underlined?) After the round-trip completes, the character is displayed normally.
[1] If you greatest stressor in software development is the latency of your keypresses, you sound very lucky to me.
[2]: https://mosh.org
If a company's security strategy relies on the ability to tell if a given stream of encrypted bytes is shell traffic, and that it can be fooled by timing obfuscation, they need a better strategy. Attackers won't care to follow a "no timing obfuscation" policy.
- All developer laptops must be able to log into prod
- You must type a 2FA pin each time you access the test environment, and that includes nightly automation scripts.
I imagine they'd love to run a thing that detected and blocked scripted access to the test environment, but allowed it in production.
(In case it isn't obvious, I agree that corporate security teams shouldn't use strange network monitoring heuristics to interfere with common engineering and ops workflows.)
Let's call that 64 bytes/packet for a small packet.
20ms/packet = 50 packets/sec = 3200 bytes/sec = 3.125KiB/s.
For comparison, a copper-wire non-broadband modem in the early '90s ran at 33.6kbps (kilobits/sec) which worked out at 4.1KiB/s. So a packet every 20ms wouldn't even saturate 30-year old modem tech. And believe me, that was slooooooow!
[edit]
After some quick googling, 33.6 wasn't standardized until 1996 (compare to 14.4 in 1991), but the manufacturers released modems ahead of the V.34 standard with DSPs so that they could be upgraded to the standard when it was available.
14.4 did catch on almost overnight in the early 90s though as the modems were no more expensive (and sometimes cheaper) than slower modems.
20 years later if someone shares their code over Google Meet I see some blurred stuff. And red font takes 3 seconds to become clear.
Though I'm curious how does the project keep working with CVS in $year, I wonder if everybody just uses git cvsimport and just forgets about CVS most of the time
Switching VCS for a project of this size is always complicated and OpenBSD devs are famously "old school" and conservative with their software choices.
I used to use CVS before switching to SVN and later DCVS like Mercurial and Git. The claim that "it is unlikely that any alternative versioning system would improve the developer's productivity or quality" is absolutely laughable IMO.
This is especially true nowadays where CVS support in modern tooling, if it even exists, is usually legacy and poorly maintained.
"Works for us". Which is a pretty good argument.
> The claim that "it is unlikely that any alternative versioning system would improve the developer's productivity or quality" is absolutely laughable IMO.
Why is it laughable exactly? I mean for me I can't use CVS due to the lack of atomic directory checkins, but if they don't need them or they have already a system in place which may even better tie with their development/release style than any generic VCS could, why bother?
> This is especially true nowadays where CVS support in modern tooling, if it even exists, is usually legacy and poorly maintained.
You make that sound as a disadvantage...
And everything is exclusionary to someone. Pure git email workflow? Exclusionary to people who find it hard/difficult, or use email in a different way (e.g. only gmail web UI). GitHub Pull Request workflow? Exclusionary to people who don't want to run non-free JS, or don't want to use "Micro$oft GitHub", or don't like using web interfaces.
In many ways, they were there first.
I really don't understand why there's such a tendency to demand "monolithic social networks" even in open source software development. Connecting to people is great when feelings are mutual, but we don't even have a right to be left alone without being accused of being anti-social?
They picked a system that suits the projects work flow, is well documented and a relatively low learning curve for anyone interested. I doubt cvs would be the main turnoff for someone looking to be an OpenBSD developer.
Maybe well documented, but "suits the project flow" and "low learning curve", absolutely not
(I mean, ok, maybe "low learning curve" if you're developing a very simple UNIX project in the 90s)
CVS is one of the tools where I literally never look back and say "ok this was nice". SVN and Mercurial something here and there. CVS? Never
There is reason Perforce, as crap as it is, is still as popular as it is.
It's a fairly small project and doesn't have too many costs, relatively speaking.
Previously the main income was from selling CD sets (they intentionally limited the web download options), but they stopped doing that about 15 years ago orso.
The rest is probably a mix of good, bad, ‘just enough’.
It's sort of a chicken-egg problem though, presumably you do have a password somewhere along the line, such as in a portal where you created your account and uploaded your public key.
Only way through it is to shut up and do it, sadly.
The implementation details of doing it are often either A) have physical possesion of computer, and do initial insecure setup within a "secure realm" you control, or B) redefine your "secure realm" to include the hardware being in someone else's possession, and do what they tell you and pray they are trustworthy.