Slashdot Mirror
SSH Vulnerability and the Future of SSL
iamchris writes "Growing complacent in regards to security is dangerous. I've become more and more dependant on the SSL-type tools for my security... ssh itself, ssl for my web content, scp, sftp, etc... We all know nothing is 100% secure (or if you don't, God help you). An article on Security Focus cites a vulnerability with SSH and passwords. We usually type them in letter-by-letter. A lot of information can be gleaned from the timing of the keystrokes and some (relatively simple) packet decoding. Is there a better alternative to SSL based tools (Perhaps TLS)? Is there anything that can be done with the clients help with the small packet issue?"
We all know nothing is 100% secure (or if you don't, God help you).
We hacked him yesterday
Unless the NSA is on your ass, nobody is going to be interpreting the keystroke frequency on your site. Why does everyone want to pretend they live in a dangerous world where weak security kills?
and even more information can be gleaned from looking over someone's back when they type. Let's be serious, guys. ;-)
If you use SSH2 protocol and Public key authentication only, you're no longer vulnerable to the password-guessing or Monkey-in-the-middle attacks as they exist today.
Back to telnet for me!
The best way I can think of is to use the RSA key authentication method. A RSA key pair is used to authenticate, rather than a password. This way, the password is never typed over the network connection.
Come test your mettle in the world of Alter Aeon!
Teraterm (available for free download here) has several SSH extensions. I beleive one of them has you type in the password all at once and then sends it as a single string, which means that key timing can't be determined. Just my 2 cents.
- Hyperbolix
yeah, it's vulnerable to a dictionary attack but at least you solve this problem...
Sooner or later someone will patch an SSH client
to go to linemode, where the client sends only
one packet for each section of the session
between carriage returns.
Problem solved.
The article pretty much says that keystroke timing can help increase the efficiency of dictionary searches.
Big deal. If your paswords are vulnerable to dictionary searches, then you have bigger problems than keystroke timing vulnerability.
This sounds like a non-issue to me.
Sometimes it's best to just let stupid people be stupid.
The timing of keyboard strokes??? Holy crap - I've just got better things to be worrying about...
Then again, perhaps my typo rate (and requisite back spaces) have helped me all this time.
BlackNova Traders
It can't be easily used to guess a password. Using a Dvorak keyboard would defeat it if they thought you were using querty, and vice versa. So would putting a timing loop with a good randomizer in the packet transmitting code. Unless you're trying to keep your data safe from the NSA/GCHQ there's little reason to worry.
Best Slashdot Co
Well, if you use RSA you don't need to type a password so that would solve that particular problem. But if you really want to be paranoid about it, the technology exists to capture your keystrokes. I believe it works by detecting the charge released from depressing each keystroke(the keyboard uses capacitance to send specific characters if I'm not mistaken). So you really need to work behind lead walls or something else that will block that signal from being transmitted.
Again, using RSA would prevent the password from being transmitted. But they could just keep listening, and gather sensitive data as you type away.
No, Thursday's out. How about never - is never good for you?
Password problem solved.
Instead of password auth, use something like s/key, so it really won't matter if the evil cracker gets:
SEWN LULU PIN HOUR PRY YEAROpenBSD supports s/key right out of the box, which is spiffy. Or use Public Key authentication, expensive crypto cards, or any of the other alternative authentication techniques out there.
While entering passwords, simply type with 1 finger, and randomly pause between each keystroke.
But if you need to worry THAT much about security, then I'd assume you have much bigger problems than that to deal with, such as the FBI or CIA or whoever it is going to such great lengths to figure out your password...
Sticking feathers up your butt does not make you a chicken - Tyler Durden
If you are using key based authentication then they are going to need more than just your password.
As I understand it, the password just allows you to decrypt the private key w/ a symmetrical cipher. Then the connection is encrypted w/ the public/private key pair. This means they actually have to have physical acess (with read filesystem permissions) to the private key as well as the password.
"A mind is a terrible thing to taste."
We just need to transmit packets regularly. One of the rules of secure cryptosystems is that you have to give out almost *NO* information via any means, whether it be the packet size, the timing, due to errors introduced into the hardware or from known plaintext or any other thing from which you could infer information about the contents or nature of the communication.
The solution? Make all packets the same size, padding them if necessary. I suspect that if we transmit regularly sized packets at apporximately even intervals, there won't be very much left to worry about. In other words, it can't be *that* hard to fix.
I wonder how long the NSA has known this?
When I connect to a remote box from Windows, I use the free ttssh extension to the freeware terminal program Tera Term. When it asks you for a password, it captures everything in a dialog box, and sends the password as one chunk.
:D
For those using a command-line version, who are really paranoid, you can just vary the rhythm of your strokes (type along with your music!). Or use RSA authentication.
But in general, I don't think anyone needs to worry about this unless they've got a bulls-eye on their backs.
Include some control characters in your passwords... For a start, none of your script kiddies will be able to figure out how to type a ^V character. Secondly, it screws type speed typing. Thirdly, a few control characters (Ctrl+C, and NULL?) are impossible to send from many Windows clients. Security through impossible passwords :)
In terms of security, there are some things that *are* perfectly secure. The one-time cipher is an example of this. Unfortunately, the pad of keys must be synchronized at either end of the communication -- and of course you can't transmit these, so practically-speaking, it's not really an option.
There's a neat document outlining "snake-oil" signs in encryption software here.
a friend of mine used to include backspaces in his typing of his password (on purpose, not just because he typed with 2 fingers).
On the other hand, what else would you expect when a bunch of computer geeks like Taco and Microsoft try to pull cloak and dagger shit like that?
If this is true, I'd like to see coverage by major news organizations; not that Slashdot is or ever has been newsworthy, but the Microsoft angle certainly is (the shareholders should be worried, anyway).
If you made all that up, you are one talented sonofabitch. Ever think about writing for the X-Files?
The best thing to do is a security audit, you need to determine whether or not you are really vunerable, or if you are a target. We have learned time and again, that security cannot depend on a single method or product. If you only depend on a firewall, and it gets hacked, you are toast. Conversely, if you are using SSH with passwords, and your passwords are weak, then what it is the point... If you really are concerned a great deal about security, you need a multi-tiered approach, where the goal is to minimize risk, you can never get rid of it, with out pulling the plugs.
It sure is sad to see how evil, and because of this so paranoid, this world has become!
but it sure makes us some money or waht?!
Just for the record, SSH and SSL are unrelated, i.e. SSH is not implemented over SSL.
I would think that unless you are a terribly slow typist that the NAGLE algorithm in TCP would defeat packet sniffing and analyzing the timing of the keystrokes.
For thos who are wondering what nagle is, it's an algorithm that helps TCP avoid sending a packet for every key stroke on telnet connections among other things.
"A lot of information can be gleaned from the timing of the keystrokes and some (relatively simple) packet decoding"
:P Sense I've switched to a Dvorak key map my finger movements have been diminished by >60%. This change in finger movements has got to also translate into different keystroke timings.
This can be avoided by altering your key timing. How do you do this? Don't use a Qwerty keyboard
Takahashi
So, take the time to learn Dvorak. You'll save minutes each day in typing, and you're hands will feel better, and it should effectively screw up any timing-based password sniffers!
Quick dvorak "graphic":
' , . p y f g c r l / = \
a o e u i d h t n s -
; q j k x b m w v z
Free unix account: freeshell.org
if you use a set pace pausing between each keystroke of password entry, no keystrokes can be discovered!
RickB
Rick B.
Checking for typing rates just seems a little too movie-esque to be realistic. It's like checking for heat residue on the keyboard or something equally ridiculous.
Also, every SSH program I've used in windows takes in the whole password before sending it along. (In UNIX I use ssh and have no idea, but it seems like it does the same thing). How could they get info out of that?
I tunnel ssh over rot13.........twice.....
This is why I always type drunk.
Ratguy
Yes, nothing is 100% secure. But we cannot judge that ssh is less secure because you can "guess" a password based on keystroke frecuency.
/bin/sh).
If this guessing method is 10, 50 or 100 times faster to guess a password, is just a sign that the weakest part on authentication systems are poor password selections. (Administrator/admin for NT is a good example)
I think that a massive password sieving is still far more dangerous globally, than a targeted password guessing.
Let's put this issue in perspective:
FTP passwords have been circulating in plaintext for years. Many of those passwords are also shell account passwords(if not, they could enable anyone to upload a cgi connected to
This is a "terrible" hole, but this is the way that millons of users upload files to their servers every day.
Considering this reality, is strange that cracks come much often from the buffer oveflow dept. (bind and nfs exploits are the top scans I've seen).
So, I'm not afraid that someone will guess my ssh r00t password just sniffing net traffic, and maybe th 98% of us should be either.
Just my 1x10-3 $
Well, while maybe a vulnerability, I don't see it as an issue. When I type what I'm thinking, i.e. passwords, code, etc, it almost doesn't matter what it is, my fingers know where to go and usually in about the same speed as any other word.
Anyways, even though I might not care, others might. Well, for everyone else, the solution seems pretty simple to me. Have the client read the whole password, then send the response to the server. Now, no matter how slowly you type, as soon as the client gets the password it'll zip it away as fast as possible.
Free Online Woodworking Resources Directory
I think this applies only to passwords typed during an SSH session, not the password during the authentication phase. As far as I know, during password authentication the password is collected and sent as a single unit, not character by character. Finding information about passwords by watching character timing's not a new attack, and there's one major problem with it: during an encrypted session, how do you tell when the user's typing a password, as opposed to moving around in an editor or something?
What's intentional is the inclusion of SSH_MSG_IGNORE message which is specifically mentioned as being useful as "an additional protection measure against advanced traffic analysis techniques." such as the one described in the paper.
The measurements of keystroke timing can be done on a broad, high-latench internet only if the Nagle algorithm is disabled. Some SSH implementations defeat the use of Nagle, in order to provide better interactive response. This can be taken out in the source code (or maybe with a configuration parameter: I'm not familiar with all SSH implementations).
When you have Nagle enabled, your keystrokes are aggregated into larger packets, because the next packet is not sent until an ACK for the previous one is received---or you type enough to send a full segment. Or something like that; I leave it to the reader to verify the details of Nagle. In any case, it's clear that Nagle can obscure the timing of individual keystrokes if the latency is high enough to cause aggregation of several characters into one packet.
Secondly, if you use public key authentication, then you won't be typing your SSH password over the network. Of course, other sensitive information may be typed, such as passwords to other systems logged into within the SSH sessions. But the SSH key itself can't be compromised by this timing attack.
doh! wrong level... yes, s/key has a dictionary attack, but at least it deals with this..
You say that you usually type them in letter by letter? What exactly do you do the other times?
No security measure is 100%, if you make a system accessable at all there are security issues. To have a really secure system you would have to embed it in a huge block of reinforced concrete and drop it in the Marianis(sp?) trench. Of course the system would be totally unusable, there are always trade-offs between usability and securty, one just tries not to balance them for the particular application.
- subsolar
It's not a crisis until leet kiddies have a tool they can use to exploit your box. A truly leet haxor is not interested in your box, but rather those of major governments.
./exploit your.host.name and get a root shell. They have no idea about packet timing or anything. It's nothing to fear.
It's the kiddie-fear mentality. Yes, script kids are dangerous, even though all they can do is type
This problem is easy to fix, use PKI or type randomly. I don't know if it even deserved a SecurityFocus article, let alone a Slashdot plug. Just a simple warning will do.
--Ted
But when you come right down to risks, passwords are well and good until the information that's password (or passphrase) protected is worth a lot of money to someone or is incriminating to someone else or something like that. You can extract a lot of information from a person with a pair of needle nose pliers. Or the bolt cutters. Cut off a fellows' big toe and threaten to do other body parts. How many here would last even one more toe? Security is relative. Your live goat porn collection is probably pretty safe. A Mafia Don's financial records probably aren't. Especially if the Godfather thinks said Don has been crossing him...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Sounds very tricky to me. What if I was typing with one hand because the other is busy? The timing algorithm would not be able to figure this one out.
You can't handle the truth.
It's a research paper that exposes a vulnerability and the fixes to deal with it.
Don't get upset, get used to it. Expect to see of these in the coming millenium.
BTW, keystroke timing is a pretty old attack. In the past, it's been used for two basic operations: One, who is it? and two, what are they typing.
Everyone has a distinct typing style that can be used as a fingerprint to identify them. If you have an audio recording of someone typing, and a database of recordings of typists with access to the machine, you can figure out which person was at the keyboard.
The more difficult problem is discovering what was typed, but with a little thought and analysis, you can probably get a good idea.
This vulnerability decreases the time for a dictionary search by about a factor of fifty. Congrats to the researchers for exposing this weakness.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
Even a one time pad is succeptable to some attacks. For instance, there's a simple tool called a gun. Apply this to the head of a person holding a copy of the one time pad. Also, there are serious problems with agreeing on the one time pad -- you have to get a copy to each point of the communication channel. How this is done can leave opportunities to compromise the security of the channel.
Who do you suppose is responsible for the problem, in the first place?
Warning: This signature may offend some viewers.
The technique was as follows:
Person A logs into the client, using a username/password pair. The client then generates an RSA keypair, using hashes of the username and the password as seeds for the random number generator.
The client then contacts a key exchange server. This takes the client public key and the server public key, generates a fresh set of keys for both client and server, encrypts them using the appropriate public key, and sends the keys back as appropriate. (eg: The client gets the client's private key and the server's public key.)
This establishes the link between the client and the server. Each then generates a secret key, using one of a selection of algorithms. (I used Serpent and Rijndael). The secret keys are then exchanged, using the public keys.
The client then uses the original username and password to connect to a Kerberos server, for a ticket.
Only at this point is data allowed to be exchanged between the server and the client, and only for the duration authorised for that ticket.
After random intervals, the secret keys are regenerated, though not necessarily with the same algorithm as before. The new keys are again exchanged with the public keys.
Once the Kerberos ticket expires, the public and private keys are replaced, using the key server. Once the keys are replaced, the Kerberos server can be contacted to refresh the ticket.
The reason for this amazingly convoluted system? I wanted a system that could run on an untrusted network, with an untrusted client AND an untrusted server.
The challange was to devise a system that provided sufficient checks that a compromise at ANY point would not yield useful information.
In practice, that's very hard to do. Compromise the database, and you have the data. There's not a lot you can do about that. Compromise the front-end server, and you can mimic anything. Again, there's not a lot you can do to stop that.
The way I approached this (and PLEASE remember that this is NOT my field, and others will have vastly superior techniques) was to insist on all data, at both ends, being encrypted as far back in the system as possible, using keys with very limited lifespans.
The idea here is to reduce the window of opportunity by as much as possible. The idea of using multiple algorithms, public-key encryption, etc, was to soak-off as much of the window as possible with trying possibilities out.
(Note to non-Wargamers: Soak-offs are where you use a trivial piece to divert a much more significant piece of your opponent, so that you can defeat what's left with relative ease. In this case, I used the "trivial" problem of picking the right algorithm to soak-off the processing power of the opponent. My "main forces" (encryption, intrusion detection, etc) could then walk right over whatever was left.)
Wargaming and computer security, IMHO, are very closely related. However, legal issues prevent me from applying my favourite tactic in "Squad Leader" and "Advanced Squad Leader" -- steamroller one flank, setting fire to everything behind me so I can't be encircled. I'd love to see a Black Hat vs. 3 stacks of 3 x 8-4-3's with HMG's, and a 10-2 leader, but I suspect that would be considered excessive by The Powers That Be.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
to be REALLY paranoid, I'd like a terminal client that waited for the enter/return key to be pressed before sending the packets - collect each command locally and only transmit upon completion. BUT the actual keypresses shoudl be immediately encrypted as they are typed in RAM - so there is never a plaintext version of the password (or in factm anything you type!)
I think Stephenson invented this idea in Cryptonomicon - it was secureEmacs or something like that...
Don't blame me - I voted for Howard Dean. http://dean2004.blogspot.com
using compression (ssh -C) will increase entropy in traffic analysis attacks against ssh.
SSH do not use SSL. OpenSSH is linked against OpenSSL because it uses some of the crypto functions in it, but the algorithms are completely different.
To answer your question, use ssh public key authentication and completely disable passwd authentication sshd_config. A password is weak compared to a public key anyway.
Saying this is a vulnerability in ssh is like saying PGP is vulverable because someone can brake your fingers until you give them the key.
Or calling any security system vulnerable because if someone sees you type the password, that can 'crack' the security.
Also, it seems to me you would have to know a lot about the person typing the password.Everything from typing speed, to state of there mind at the time of typing the password.
The Kruger Dunning explains most post on
...and sending them over the wire. You can generate id's and use them for remote ssh access. see ssh-keygen(1), then when you type your password it is only used locally. nothing is send until your id is decrypted. and then using this is the authentication done.
Simple solution: Just enter in all of you password with the left hand. That will infuse half of the keyboard with extra time noise as you search for keys that are unfamiliar to half of your typing insturments.
Oh,... wait... BAD IDEA. I think too many people here are already proficient at typing with one hand...
______
Once: you're a philosopher. Twice: a pervert.
There seems to be some confusion as to the nature of this attack on ssh. Some facts may be enlightening:
I am not one of the authors. Everything I write here is the result of informative discussions with Dawn Song, one of the authors on the ssh paper.
All ssh implementatons send your password in one packet (when using password authentication). However, if you ssh from A to B, and then from B to C, the fact that your password is sent from B to C in one packet isn't helping you a whole lot, since it was sent one character at a time from A to B. Using RSA authentication doesn't help, since you have to enter a password to access the key stored on B. This password will be sent one character at a time from A to B. This multihop ssh-ing is a common practice, so this is a serious threat.
Sombody else claimed that it was only effective against passwords which were susceptible to a dictionary attack. This is a non-sensical statement. The best way to describe what the attack does is in terms of bits of information gained, but I'll simply say that, with this attack, you usually only have to search about 1% of the possible passwords to find the right one.
Others have suggested using one finger to type, or using a dvorak keyboard, or deliberately typing in a random fashion. Using one finger or typing randomly will work. However, a dvorak keyboard would only change the keyboard model. The attacker could still perform the same attack, but using that model instead of the qwerty one.
As for remedies, inserting random jitter in ssh is not effective. By watching several logins, an attacker could average out the jitter to get the real timings. Changing ssh to send packets at regular intervals, or using line mode, will eliminate all timing information.
Although this attack was presented in terms of gathering passwords, it's also effective (perhaps even more effective) for recovering english text. In fact, the information recovered is about 1.2 bits/keypair, and english only has about 1.2 bits/letter of entropy. So in essence, because of this attack, YOU SHOULD CONSIDER SSH TO BE EFFECTIVELY EQUIVALENT TO NO ENCRYPTION AT ALL. You should not make light of this attack unless you would be willing to use telnet.
Somebody also said that this was extreme paranoia because one could just park a tempest van outside your window to get the text you type. But tempest vans are expensive and hard to operate. Breaking into routers is easy. This attack could easily be scripted, but I know of no tempest-van scripts in wide use. So the threat here is tremendous.
The best solution is to randomize your typing until ssh is modified to send packets at regular intervals.
Best,
Rob
As0k
Keystroke timing is different for us dvorak typists... its more regular due to the efficient design.
Don't all ssh clients send the password in one packet after reading them in? Even further, don't the newer versions pad the password to the lenght can't be guessed? I would suspect that this attack would only work on passwords typed after logging in (e.g. su).
I know the problem is theoretical, but when people were talking about breaking encryption (rsa for instance) originally, they said it would take quadrillions of computing years. Now in the era of fast(er) computers, and (distributed networking models), keys are easier to break. Were the original people who made the 'practically unbreakable' claims thinking of today? Obviously not, because it wasn't a quadrillion years ago that the original claims were made.
-yb
Wow, you were close. Just like I was close that time i shat in the bathtub.
When I was looking up info on the nagle algorithm, I understood it to be used for high-latency lines (dialup), and that it wouldn't work on a LAN, for instance ...
The other thing is that sure, you can log into a remote machine and originally authenticate by keys, but what happens when you 'su -' to do something?
-yb
...is that touch typists are more vulnerable than hunt-and-peck typists?
*Throws copy of Mavis Beacon out the window*
Hi all,
I was at the actual talk at USENIX last friday. The article missed few key points.
First you can get some idea of what is being typed by examining the network traffic and looking at what's echoed since character are sent one at a time.
Something like su\n is easy to find because it's two characters that are echoed and then another character and then the server send 13 or so bytes to the client.
You can also tell when the password is being typed because the characters aren't echoed back to the client.
All you need is a sniffer on the same lan as the client to do an attack like this.
They claimed that by combining this with key stroke timing they were able to significantly reduce the effective entropy of random passwords.
I case your wondering no they haven't tried this with a dvorak keyboard. And yes using hunt and peck typing is a simple way to protect yourself from this.
Is is just me or are geeks in general overly ridiculous about security?
A lot of information can be gleaned from the timing of the keystrokes and some (relatively simple) packet decoding.
C'mon, raise your hand if your terminal sessions are the target of a spy agency...
I mean really, who cares about your little geeky passwords to your linux boxes enough to go through all this? Not to mention the physical limitations...
SRP - Secure Remote Passwords. A stanford project that isn't vulnerable to timing attacks found when typing passwords over an interactive connection.
Also, to "fix" ssh, just don't send passwords as you type them; wait until enter is pressed and always send a fixed length chunk of encrypted data.
I love putty, and actually use it far more than CygWin, even though they're both on the same winbox I got here at home...
Need a Linux consultant in New Orleans?
Login is not the only application of passwords. Many people enter passwords for su or sudo. Such passwords are vulnerable to this attack, in the sense that it would make it 50x easier to crack a stolen password file.
Is the rhythm I use for my password entries!
-- Trolled...you WILL be === Yoda
Oh wait no. My message is gonna be something in the 2.2million range! So much for all them first post-ers!
I usually just mash the keyboard with my fist in one shot. Sure, it takes a little longer than normal typing to get the right password, but no one's going to be guessing MY password.
--
"Karma can only be portioned out by the cosmos." - Homer Simpson [1F10]
A couple points:
- one guy using a Dvorak keyboard won't reduce the vulnerability of the network as a whole, as there will still be enough users providing keystroke timing data to weaken ALL passwords on the network, including the superuser account passwords.
- If EVERYBODY on the network switched to Dvorak keyboards, the attacker need only create a new statistical model to discern the keystroke timing patterns in this new environment. Easy enough, since it has been shown to be possible for QWERTY environments.
- Ditto for a mixed environment (why? the data set for any single environment is probably orthogonal (separable) from every other dataset)
Conclusion: switching keyboard layouts to defeat this attack is a dumb idea.
I don't think I could pay someone enough to try that hard to figure out my passwords. I must be such a loser.
So in other words, the strategies they describe here for attacking SSH could be equally effective for most any asynchronous network protocol where you could try to infer information from the rhythm of the rate of data transfer. Further, there is ultimately no general solution, only incremental defenses against the general strategy:
So, as is often the case, if you want perfect security you can only have it at the expense of tremendous overhead, and ultimately you have to decide how far you want to take your defense against chaos theory before deciding that you just have to accept a certain degree of risk. Ultimately, there is no defense and you always have to accept that risk.
DO NOT LEAVE IT IS NOT REAL
Nietzsche was a prat
Where is the parent gone ?
It was there 10 minutes ago !
I'm preparing a contribution to policy where I work which includes several stipulations on the use of SSH.
First, password authentication should be disabled, in favor of public key authentication. Second, only encrypted private keys are allowed for login sessions; an ssh agent will be recommened to minimize the inconvenience of repeatedly typing pass phrases. *Long* pass phrases will be recommended. (Note that you can't actually enforce the last two, they're just a matter of procedure.) In cases such as automated scripts which can not use encrypted private keys, a key pair will be generated *for each task*. The public key, when installed, will have the command specified so that the key pair can be used to execute *ONLY* one command.
In addition, all authorized public keys will be kept in a document on an HTTP server. A cron job (python script) will run at least once a day to fetch that list, and compare all of the private keys installed on the system to the authorized list. Any key which isn't in the master list will be removed from the system, and the network admin will be alerted.
Maybe similar procedures would benefit others. Does anyone see holes in this procedure?
Probably, a lot of the gain in cracking efficiency is due to simply the character transition probabilities (e.g., 'q' is almost always followed by 'u'), independent of their timing. In that case, simply obfuscating the timing might not help all that much.
If you want a truly secure connection, you need to use public keys, like others have said. But there's more to it. SSH users need some education. Here are a few things I have learned.
In fact, with KDE (I'm sure there's an equivalent for your favorite WM or operating environment) you can just add a script to ~/.kde/Autostart that lets you type your SSH password when logging in:
#!/bin/sh
ssh-add </dev/null
I believe this requires the "ssh-askpass" package to be installed.
But you can correct the situation by port-forwarding an SSH session. One way to do this is on your own box type "ssh -f -L 2222:otherbox:22 firewall sleep 60" then type "ssh -p 2222 localhost". That way your box encypts the session twice, the firewall decrypts it once, and the other box does the final decrpytion. (After the sleep timeout is over, the forwarded connection will not terminate until you terminate it.) You can write a shell script that does all this for you. I have a script that uses "netstat -tln | grep 127.0.0.1:2222" to set up the forwarding automatically if it has not been set up.
Hope this helps!
Use Zope!
What about the timing when using other keyboards layouts like dvorak? I'm assuming this study was based on the more common qwerty layout.
:P
Does this mean my dvorak keyboard is a little bit more secure than your qwerty keyboard!?
To combat the keystroke issue, just get a programmable keyboard and put the password in it. Of course then if your keyboard is stolen, they might be able to get the password, so yet again, it is an imperfect solution.
I don't read AC posts...want to be heard? Grow a set and log in.
But then we lose our privacy!
SSH sends the whole password at once (in SSH 1.2.31, sshconnect.c, lines 1786-1794). The issue is when you are typing something over an SSH connection. At this point, each keystroke (approx) gets sent in a separate packet to the machine you're connected to. So an attacker gets ~1 bit of info/character as you type.
If the attacker knows when to look, they have some chance of guessing a password you type over an SSH connection, either for the next hop, for su, or for something else like that.
In the case of connecting to a 3rd host, they get tipped off as to when to look by the 2nd connection; you form the 2nd connection, and then type your password over the 1st connection. Note that this attack requires that they detect both connections, and make timing measurements on the 1st one to get the password on the 2nd.
Given typical typing speeds (hardly less than 100ms per key press) and the round-trip delays usually observed today (in the 50ms range), the Nagle algorithm doesn't have much effect here: when you type the second key, the client has already received the ACK for the packet with the first key press sent earlier, and sending the second key press is not delayed at all.
Is the password prompt on SSH actually a two-way connection? I always thought that the client buffered up the password, and then sent it in a single packet. That would help with some SSH connections (just connecting from one to another), but not when you connect to one system, then jump to another, and another.
Secure connections could send random amounts of null data at random times. To make it a lesser bandwidth problem, only have this excess data be produced when the client is sending stuff (ie, keep sending junk for a few seconds, then go quiet until the next keypress). It wouldn't be recommended for slow connections (like with modems) though..
Also, you could try to use different keyboard layouts (dvorak or other) to make it harder to guess what key is being pressed at a particular time.
So, take the time to learn Dvorak. ... it should effectively screw up any timing-based password sniffers!
Not so fast. The choice of Dvorak or QWERTY adds only one bit of entropy, merely doubling the possible dictionary/brute-force keyspace to check. This poses no problem to attackers whose computer power increases exponentially with time. (I wonder why distributed.net 's keyrate appears to increase linearly though...)
Will I retire or break 10K?
Solar Designer, a security researcher at Openwall, and Dug Song, one of the OpenSSH developers, have independently discovered the same basic attacks (the details are a little different).
r af fic-analysis.txt
http://www.openwall.com/advisories/OW-003-ssh-t
It mentions that the latest versions of most SSH implementations include rudimentary countermeasures. While not perfect, the two researchers mention that the measures *do* prevent most of the attacks from being successful.
In other words: it's not as much of an issue as people think. Especially not if you're using OpenSSH 2.5.2 or later.
or someone working in other defense/intelligence agencies, it's an issue (though methinks that there are easier ways to get information). However, the average Joe Blow on his dorm Ethernet just doesn't have to worry. Your SSH1 connection really honestly isn't going to get attacked. Why would you? There are sure to be a hundred *other* potential victims using plaintext telnet just next door...
2205262th POSTUS, BEEOTCHAE!!!
Bow down and tremble before my flatulent magnificence!
pleeeeease?
Even if you just added some randomness to the user input as some proposed, still there would be statistical information that could be used. The more often you can sample the data the more accurate it does get, that's the idea of statistics!
Still these statistical methods alone won't lead to a practical attack, but together with other methods it could lead to something if we didn't do anything against it.
Same's true for any encryption system I know of. There's a relatively high-security PRNG that you can build with relatively little effort (and without spending too much).
1) Purchase 3 12-packs of Jolt.
2) Drink them. All of 'em.
3) Now keep one hand on the mouse. Your ceaseless jittering will generate enough entropy to keep the Linux PRNG happy for a long time.
Hey Moderators,
did you read any of the comments to this high rated article? Then you would have seen that what he says about safety through nagle's algorithm isn't informative but inaccurate and dangerous...
Buffer the passwords on the client then send them when you press the enter key...?
Turn on some music, and enter your password to the rhythm of the music, using one hand for the keys and the other for case shifting.
To be honest, the paper doesn't show much evidence that significant information on passwords can be recovered using this sniffing technique. It is most efficient if you have got a detailed typing profile of your victim. The authors claim that this can be obtained in most cases, but I doubt it. Using the profile of another person doesn't seem to give good results (although Table 1 in the paper is pretty confusing).
my school, U-Mass Lowell, (cs.uml.edu) , recently switched all its logins (shell, ftp, etc) to SSH, because too many boxes were getting hacked. Now I guess it's time to move on to something even better. Well, I have only one more year until I graduate from the CS department anyways, so hopefully they at least wait one year before changing it again.
Reason, free market capitalism, and individualism
It's easy to say that, I know, but it's true. :-)
When I first started using ssh, I thought of this. I mentioned the idea as a security vulnerability to a friend, and he dismissed it. I should've written it up, but I felt I should do tests first.
A good way to defeat this is to have ssh send packets every tenth of a second unless it hasn't gotten any data to send in more than 15 seconds, or if it has a lot of data to send. In the first case (no data for 15 seconds) it should stop sending, and in the second case it should send as soon as it has x (where x is probably something like 256) bytes of data to send.
This will add latency, up to a whole 100 milliseconds worth, but that would greatly reduce the problem.
Need a Python, C++, Unix, Linux develop
Geez, the makers of these unix products are so stupid. When asked what they were going to do about this vulnerability, they responded that they were going to try to do what they can to increase the computational infeasibility of this security hole. Just like those unix people to resort to security through obscurity, as always.
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
If you're going to be paranoid, why be paranoid by half measures?
I do not deploy Linux. Ever.
If it's that important, are you really going to trust an off-the-shelf product for your security? Especially one that has open source code? If what you're protecting is going to compel someone to sniff your network for packet patterns, should you be trusting an open network?
For the rest of us, what level of paranoia justifies going to greater lengths than SSH/SSL? What's the likelihood that someone's sniffing random packets and appying heuristics to find my password or credit card number? Wouldn't it be easier to get that info by looking on my desk or in my wallet?
- Sig this!
Select a password over 7 characters in length, using mixed case, both characters and numbers ... oh yeah - and pause between each character entered.
BITTER
* 2001-08-22 16:19:50 ssh vulnerable to keystroke latency attack? (articles,encryption) (rejected)
/BITTER
You moderators have been harsh today.
Now, if someone decides to target me and is able to sniff all my traffic for several days, then if they harness all the computing power in the world, they could crack my user password in a measley few milleniums!
If you have to use a password (because RSA/DSA etc) aren't available you can always type random gibberish for 20 or so keystrokes then hit Control-U and then type your password (all in one smooth motion.)
Padding with trash to defeat a known known plaintext attack is an old trick.
"Aiiieeee!!! The yellow face, it burns!"
for (i = 0; i < options.number_of_password_prompts; i++) {
if (i != 0)
error("Permission denied, please try again.");
password = read_passphrase(prompt, 0);
packet_start(SSH_CMSG_AUTH_PASSWORD);
ssh_put_password(password);
memset(password, 0, strlen(password));
xfree(password);
packet_send();
packet_write_wait();
type = packet_read(&payload_len);
if (type == SSH_SMSG_SUCCESS)
return 1;
if (type != SSH_SMSG_FAILURE)
packet_disconnect("Protocol error: got %d in response to
passwd auth", type);
}
Many people do not understand this. Some believe they are protecting themselves from this risk via RSA authentication. Of course they're not, because the risk only affects passwords in session:
- gorf: My solution is simply not to use passwords at all; I use RSA keys exclusively...
- SagSaw: The best way I can think of is to use the RSA key authentication method. A RSA key pair is used to authenticate, rather than a password. This way, the password is never typed over the network connection.
- Pinball Wizard: Well, if you use RSA you don't need to type a password so that would solve that particular problem.
- subsolar2: I use RSA authentication for remote access, and have since day one. So the only real worry is somebody getting a copy of my private key...
- Greyfox: As has been noted, RSA is the way to go, at least with SSH authentication...
Others think that a GUI client is more secure entering a password in a dialog box suggests batch processing:- stripes: My Java ssh client happens to have "gotten it right" not because I'm smarter then other ssh client authors but because I had a dialog box to ask for the password.
- Hyperbolix: Teraterm
... has several SSH extensions. I beleive one of them has you type in the password all at once and then sends it as a single string, which means that key timing can't be determined. - rgmoore: I think that most Windows terminal emulators have similar functionality. It seems like a very simple step to take to help preserve passwords.
- garcia: don't most GUI terminal packages (including MacSSH, etc) all send it as a single string (SecureCRT)?
- Rimbo:
...I use the free ttssh extension to the freeware terminal program Tera Term. When it asks you for a password, it captures everything in a dialog box, and sends the password as one chunk.
- Jormundgard: Also, every SSH program I've used in windows takes in the whole password before sending it along.
The very few who got it:Quoted text from IETF draft follows.
Quoted text from IETF draft ends.
I think you deserve at least (Score:3, Funny)
Regarding the keystroke-timing guessing, just use Nagle's algorithm. It holds on to keystrokes a set amount and sends them together (the algorithm is based on the average gaps between keystrokes). Then 2-3 keystrokes get grouped in the same packet, and I'd guess the keystroke-timing attack should be thwarted.
Cisco routers support it (service nagle), and I'd guess there is a way to have sshd, etc. support it as well. Of course, Cisco routers/PIX firewall only support sshv1, but it's better than plaintext, and inbound management sessions should be limited by IP addresses anyway.
what i haven't seen in this discussion (maybe an anonymous coward mentioned it, but i don't read 0 score posts) is TIS authentication via cryptocard. it totally defeats this type of sniffing because the string you send is always the same length, and non-repeating (i.e. the authentication string i send this time isn't the same as it was last time, nor will it be the same next time). the down side is you have to carry your stupid cryptocard around, but that's no worse than the "removable-media keys" suggestion someone brought up earlier.
of course, things like sudo and su don't support cryptocard-style authentication yet, but it's possible.
oh, and it's not free, but if security is so big a concern for you that you're afraid of someone sniffing kestroke timing on passwords then you really shouldn't balk at paying for solutions.
"Mister Potato-head --MISTER POTATO-HEAD! Backdoors are not secrets!" (War Games, 1983)
Who in their right minds allows for password authentication over SSH? That's one of the first things I disable when setting up SSHD.
If you don't have a private/public key pair, and if your public key isn't in the authorized_keys file of the target machine, then you don't deserve to log on. Tunneling passwords over the system is neither needed nor safe, and not just because of this article's hack.
If you allow SSH to do password authentication, then SSH is little better than Telnet in terms of protecting you from a poorly chosen password. While a sniffer might not be able to extract the password, you can still try a dictionary attack.
Force your users to use a keypair. Force them to put a passphrase on the keypair so that just stealing the key isn't enough.
Remember, the best security is something you are (restriction by host IP), something you have (posession of the private key), and something you know (the passphrase for the key.)
www.eFax.com are spammers
It's not your field. But then it's not mine either :-) But...
I assume you add a nonce/timestamp into your PRNG seed. Otherwise you'll be using the same seed each time for each user. Bad. Maybe confusing 'random' with 'unpredictable'? Or does the password change over time?
Except as the client doesn't have knowledge of the server public key (or if it does, it's not said here), the protocol is vulnerable to a man-in-the-middle attack from the word go. All this stops when the Kerberos server gets involved, but it's an effective service denial attack, as the client/server never get to exchange key material.
You are (if I've got this right) basically generating another key pair for key exchange (see below). Except that this time it's the server doing it, so you're trusting the server, and all the client has demonstrated (in terms of trust) is the ability to create a key pair. How does the server confirm the key-pair<->user match?
But you've already done this. Now, however, the server has the client private key, and you have to trust the server not to misuse it and not to get compromised, whereas before you were trusting the network to point the client at the server and not at a malicous proxy :-)
The key's are for the Serpent/Rijndael ciphers? Or Serpent/Rijndael is used to generate the keys? Excuse my lack of clue :-)
It would seem in this situation, that having brought a Kerberos server into the picture, the previous messages were a mere formality. I take it they were intended to secure the pipeline between the client and the server, but as I said above, you can have an MITM on the server as the client has no foreknowledge of the servers' public key.
I take it that refreshing the key material/key-exchange key pair regularly is to limit damage if anyone discovers them.
Unless I'm wrong, you're trusting the client to generate the initial key pair. You're trusting the server to generate the key pair used to exchange keying material, and you're trusting the transport not to MITM the server in the second paragraph.
Excluding the Kerberos server :-) And assuming that the server doesn't retain the private key it generated for the client.
I think that someone wishing to compromise your network would use other means than protocol/cipher attacks. I know I would :-) so your soak-off is effective in this case, because you have things like physical security, social engineering, etcetera which are an equally great threat to your network/data.
I assume you also use other primitives (digests, etc.), along with some form of authentication before all this even starts, because while you cover interception pretty well, there's still invalidation, impersonation, and service denial, among other things.
The other question is, if you're on an untrusted netork, how can you rely on the availability of any parties? E.g. someone could SYN flood the kerberos server.
Which is probably because of the similarities of both fields to actual warfare (albeit guerilla warfare) :-). Schneier has covered this recently
Excuse me I've missed something, misunderstood something, or made an assumption, seeing as it's not my field :-) Your comments appreciated.
Personally, I was under the impression that they were doing this in the first place. Guess I was wrong.
"I don't know that atheists should be considered citizens, nor should they be considered patriots." - George Bush
(Note to non-Wargamers: Soak-offs are where you use a trivial piece to divert a much more significant piece of your opponent, so that you can defeat what's left with relative ease. In this case, I used the "trivial" problem of picking the right algorithm to soak-off the processing power of the opponent. My "main forces" (encryption, intrusion detection, etc) could then walk right over whatever was left.)
I believe the military refers to this as "defeat in detail". A very potent technique _if_ you manage to fool your enemy.
Wargaming and computer security, IMHO, are very closely related. However, legal issues prevent me from applying my favourite tactic in "Squad Leader" and "Advanced Squad Leader" -- steamroller one flank, setting fire to everything behind me so I can't be encircled. I'd love to see a Black Hat vs. 3 stacks of 3 x 8-4-3's with HMG's, and a 10-2 leader, but I suspect that would be considered excessive by The Powers That Be.
Excessive? You aren't even calling for artillery support or air strikes! It'd do most of these villains good to find themselves in a good Napalm or FAE strike.
-- Mal: "Well they tell you: never hit a man with a closed fist. But it is, on occasion, hilarious."
Only joking.
That frightens me.
(...) We usually type them in letter-by-letter (...). hmm, I always type letter by letter. My keyboard doesn't have 2 letter keys :-)
http://www.mwbrooks.com/dvorak/dissent.html
Nerd: Derogatory term typically directed at anybody with a lower Slashdot ID than you.
(from the Securityfocus article)
I see how packet capturing could lead to a vulnerability in this. What I *don't* see, is why in the HELL anyone would want to send each letter of the password in a single packet!! I don't see any security benefit to it, and it would seem to make cracking the password slightly easier. It would seem that sending your entire password in one chunk would be more secure.
Can anyone explain to me WHY ssh would do this?
-Kasreyn
Kasreyn: Cheerfully playing the part of Devil's Advocate to hairtrigger
timing-based attacks aren't new; most people can remember time-based attacks regarding TCP sequence prediction (older windows, IRIX, many others) and so of course the initial reaction is that we need to make XXX protocol (fill this one in with SSH) not-suceptible to this attack.
oddly enough, there's nothing about the SSH protocol that's to blame; only a matter of convenience in implimentation: SSH sends one packet at a time so that things can seem as speedy as possible. this is common with interactive protocols, and I should say "a good thing".
if people think it's too big a deal, several "code" things can be done: either batch up several keystrongs (turning up the compression level is one way with some ssh clients), or modify SSH to add some white-noise when keystrokes are being emitted slowly. a third one could be to impliment local flow control (^Q/^S) so that SSH would burst passwords together.
unfortunately, the first two of these can actually slow things down a bit, and the third just seems silly (and i don't think emacs users would like having their precious confusing control keys taken away or quoted)...
Yet another crippling bombshell hit the beleaguered *BSD community when last month IDC confirmed that *BSD accounts for less than a fraction of 1 percent of all servers. Coming on the heels of the latest Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinfore what we've known all along. *BSD is collapsing in complete disarray, as further exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood. FreeBSD is the most endangered of them all.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick nd its long term survival prospects are very dim. If *BSD is to survive at all it will be amongOS hobbyist dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For ll practical purposes, *BSD is dead.
*BSD is dying
Just use the password: "password"
works just like a charm! no one would ever think of trying it!
umm....uh....did I just say that out loud?....ooops
I'm out of my mind right now, but feel free to leave a message.....
Ok, for a bank or the NSA, I can see needing Nth level encryption and other secret-spy stuff.. bot for joe webmaster or taco logging into the slashnet servers we dont need military grade security. Yes, fixing a hole is a great idea. but we dont need to be running around screaming OMG!!!OMG!!! ssh is insecure!!!! WEll it was insecure when it came out, and it will be forever insecure. you want secure? lock your box in a safe with all drives and ports filled with cement. and not on a network.
That is the only way you can call something secure.
Do not look at laser with remaining good eye.
Looks like you've got the begining of SRP, but using creative seeding for RSA key generation is *BAD*, so you are likely not at all secure.
Look up SRP for an algorythim which is provably secure for what you want (mutual authentication via password).
Randomize the net.
A lot of people are missing the point. This just doesn't apply to "sniffing passwords" (whether or not the client sends the password in a block or per character, I don't know) during the authentication. This attack involves analyzing the traffic sent back and forth.
For example, Alice works at an ISP. When she connects to machine Bob, the first command she usually issues is "su - root". Now, if Charlie knows this, or even that it is typed at all during Alice's session, he can capture the traffic, and he's got the beginnings of a plaintext attack. He knows what the first 10 characters are, he knows there will be a pause, followed by the root password, followed by another pause. It is then fairly easy to guess that the next to characters will be either something like "ls" or "cd".
This goes beyond sniffing passwords -- it's a whole traffic analysis attack, giving known plaintext to analyze the ciphertext with.
An earlier poster tried to point it out (with a +5 summary, no less)...I have to say that this makes me worry about the topics on the board about which I *don't* have knowledge...
In a nutshell: SSH is like https...it sets up a tunnel between the client and the server that is encrypted. It uses the RSA algorithm. This requires a public key on the part of the server. They are not worried about SSH that doesn't use RSA: those implementations must always pass a key in cleartext, so they're not worth discussing. So far so good?
OK, once the tunnel is set up, you then use passwords (now and then) to log in to various hosts, go su, etc. Those passwords are sent thru the SSH tunnel...and if they're done on a keystroke by keystroke basis...viola! You can infer the identity of the key by the interval between that key and the prior (i.e. an "E" may come close to an "N", or something like that). That's it. So few people seemed to get this, that it is a little worrisome (although I admit that I hadn't considered non-RSA ssh protocols, which do exist. BUT WHY???)
i was just kidding.
Takahashi
When I connect via my SSH telnet client it, a logon window pops up where I type username and password which then gets sent at the same time.
I also compress my transmission to increase the speed, which I guess will make small delays in what I send in order to make the chunks of data big enough so that the compression work.
But I get the idea.
I thought everyone was making such a fuss because one could sniff the timing on the SSH session password. Any other passwords you send while connected would seem likely to be more secure to me, since an interceptor would have to first figure out which part was a password, and which part was just text and command line entries entered during the session. ("Hey, I've got it!! His password's 'pine-iqylogout'!!") =P
-Kasreyn
Kasreyn: Cheerfully playing the part of Devil's Advocate to hairtrigger
what happens when you 'su -' to do something?
That's assuming you can even find an su amongst all the encrypted traffic.
--
Later
Corrado
KangarooBox - We make IT simple!
test post, go away feeble trolls
Mental note to self: Read the article first and then post.
Sorry!
KangarooBox - We make IT simple!
Perhaps a future version of SSH could add a buffering mechanism that sends the whole buffer at regular (or randomized) intervals if the outbound buffer is not filled to a point where it would be deemed non-human input.
How about also padding a "regular-interval" packet with a random amount of random data to also avoid the size of the useful portion of the datagram from being calculated.
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?