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?"
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.
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
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
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
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.
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.
Or you happen to have a cable modem. My Road Runner connection has an average of 40-50 hits a day that are: Code Red scans; various trojan/vulnerability scans; port scans. The vast majority are script kiddies -- but the environment is like the old Wild West. No law but the fastest firewall.
(The good thing is that it gives me LOTS of useful experience with Snort, AIDE, Tripwire and other tools.)
Sniffing is also done quite a bit (from what I've heard on IRC channels). I've done it myself (ksniffer is real nice).
On shared networks this sort of thing is almost trivial.
Learning HOW to think is more important than learning WHAT to think.
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.
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.
This is why I always type drunk.
Ratguy
And just for the record as well, TSL is just SSLv3.1. It was given a new name be SSL was trademarked by Netscape.
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?
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.
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.
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.
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
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
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.
Just to be clear, you should use a password with RSA keys (otherwise, for instance, root on the system that has your RSA key can impersonate you on the remote system). However, as I understand it, the password used is used to decrypt the RSA key prior to use, and then the decrypted RSA key is used. So yes, it should protect against this (very theoretical) attack.
But then, you were already using RSA keys so that knowing your password on the remote system wasn't sufficient, right?
As an aside, I've found that those cute little credit-card CD-ROMs are excellent for storing your RSA key, and they're usable with just about everything but TiBooks and iMacs - and with the extra space, you can keep known-good SSH binaries for Windows, Mac, and any Unix systems you commonly use on there as well.
--Matthew
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]
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
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?
Argh! This has *nothing* to do with ssh password authentication. It's about typing passwords via ssh after the connection is established. Ssh2 does have a 'keyboard-interactive' mode of authentication, but it's the least preferred so it doesn't get used much.
Try running tcpdump to capture a password-based ssh login. You won't see one-packet-per-key unless you happen to be in that unfortunate keyboard-interactive mode.
Ssh password authentication does not leak timing information.
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.
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.
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.
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.
Select a password over 7 characters in length, using mixed case, both characters and numbers ... oh yeah - and pause between each character entered.
It's really hard to work out a good scheme to do this. The problem is that the user wants good interactive response so when they type a character, you have to send something right away. You can send a lot of garbage as well, but how do you make sure that the attacker can't tell the difference between garbage and the real data? Probably only by sending garbage constantly! That would massively increase the bandwidth requirements for SSH.
You should read the paper. It's easy to see when people are typing passwords because the client is sending characters but the server is not echoing them back.
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:SRP doesn't help here at all. The attack here is when you're logged into machine X using SSH and then you type a password to be used by machine X to log into machine Y. SRP does not help you securely get the password text to machine X.
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
1) Create a non-root user and add them to the wheel group
2) Disable ftp access to members of the wheel group
3) Disable ssh logins from root
3) Allow only members of the wheel group su privilages
No problem.
Except because of an INSANE (IMHO) argument from RMS, GNU su doesn't support the wheel group convention.
I guess you could always just chmod the su file so that only members of the wheel group could execute it...
load "linux",8,1
(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
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.
Yes, the date/timestamp was used to salt the seed. (Hey! Salted sunflower seeds!
The client doesn't know anything about the server, at the start. It only knows about its own keys at that point. The key server knows the initial public keys of both server and client, and then both key-pairs for both server and client. This information is securely wiped after being sent. After the exchange, the client knows the server's public key, but not its own.
The client and the server aren't interested in validating -who- they are, per se, initially. What they are concerned with is establishing a line of communication which is effectively untappable. Once that line has been established, the line is considered secure enough to send the identifying information (eg: the Kerberos login and ticket). That information is then used to authenticate.
The purpose of setting up a secure line first effectively blocked the SSH attack mentioned earlier, of examining delay between keystrokes, packet-size, etc. Because you don't know -how- the data has been encrypted (only that it has), you don't know how the packet sizes compare.
The keys are for either the serpent or rijndael cypher. Which one is picked entirely at random, each time this stage is completed. To make sure that both client and server are expecting the same algorithm, the choice needs to be sent over the public-key connection.
Because the encryption code was the same for both the client and server, the server must also authenticate itself on the Kerberos server. (Oops! Forgot to mention this.) This means that the server can authenticate itself to the client, in the same way as the client does to the server.
Yes, refreshing is to limit the damage. If any one key is obtained, then anyone with that key can systematically break any information in the chunk that that key was valid for, assuming they logged every packet. By changing the secret keys frequently, then the direct damage possible is very minimal. All they can do is read, and only a small chunk at that.
If a public or private key is compromised, then you've a tougher problem, as these carry the secret keys and methods. The best I could come up with there was to use two rounds of public key exchange, to make it difficult for someone to keep track of who's keys are who's and for what. It's not foolproof, but it's something.
The Kerberos server is "vulnerable", but as it is talked to via this virtual private network, it can be "behind" the main server, and therefore not visible to the outside network.
Physical security is a problem, yes. That is tackled by having a distributed system. (You've three servers, but you don't necessarily know which one does what.) Because of this, even the administrator doesn't know, at any given power-up, which machine is doing what. A physical attack would require the compromise of ALL machines in the group to be compromised. This doesn't -stop- a physical attack - you can't, really. All you can do is scale up the problem to make it impractical for the information.
Social engineering is another difficult problem. Anybody can figure out the username and password for a person. The only way to avoid this would be to have client-side certificates, but your average user is unlikely to want to mess with those.
All in all, the "best" way to limit the damage of social engineering is to have the user input as LATE in the process as possible. That way, you've got to dig your way through all the other layers in order to even make use of the information.
Hopefully this clears up the concept up a little. As I said, this isn't my field, so any inaccuracies are entirely due to my pet hamster lying to me.
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)
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