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

Comments

So what?

[Reality Master 101]

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.

Not about login password

[crucini]

This is not about intercepting the ssh login password. It's about interceping passwords entered during an ssh session. Here is the relevant code from sshconnect1.c in OpenSSH:
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:

1. gorf: My solution is simply not to use passwords at all; I use RSA keys exclusively...
2. 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.
3. Pinball Wizard: Well, if you use RSA you don't need to type a password so that would solve that particular problem.
   
4. 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...
   
5. 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:

1. 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.
   
2. 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.
3. rgmoore: I think that most Windows terminal emulators have similar functionality. It seems like a very simple step to take to help preserve passwords.
4. garcia: don't most GUI terminal packages (including MacSSH, etc) all send it as a single string (SecureCRT)?
5. 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.
   
6. 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:

1. Ethan: It's a moot point with SSH anyway, because SSH transmits the password in one chunk as far as I know...
2. Todd Knarr: I think this applies only to passwords typed during an SSH session, not the password during the authentication phase.
3. rtj: There seems to be some confusion as to the nature of this attack on ssh...All ssh implementatons send your password in one packet