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

TeraTerm

[Hyperbolix]

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

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.

Re:SSH2 and Public Key Authentication

[stripes]

That won't quite work; ssh has no idea when you are typing in a password, and when you're expecting an interactive response. Imagine using the passwd command during an ssh session; how does ssh know?

The ssh client doesn't know in general when you are typing a password, but it does know in specific when you are typing the one to start the session. 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. I expect a lot of other window system dependent ssh clients work the same way.

The only problem with this solution, though, is that su-ing can reveal a password.

Or entering passwords for things on the remote host (like things on the serial devices). However the attacker needs to somehow know when you are entering this other password. It won't normally be easy for them to know. Unless they have created a problem, and called you to ask you to fix it... you can type you password locally and paste them into the ssh client, but that seems painful, and it also mean you password is in the local cut buffer which is an attackable location (and also you might paste it somewhere you didn't want to...). Blech.

Re:This is a serious attack

[kurowski]

YOU SHOULD CONSIDER SSH TO BE EFFECTIVELY EQUIVALENT TO NO ENCRYPTION AT ALL.

Well, not exactly. See, I don't really care if people can recover the English text that I type in an ssh session, since it's generally email which will be sent out unencrypted anyway. But I do care that they don't recover my password. And since my password isn't English, it has more than 1.2 bits of entropy per character. (let's see, upper+lower+num+puct... about 6 bits per character).

So while I wholeheartedly agree with you that this is a serious attack, I don't agree that it reduces the security of ssh to that of telnet.

SSH public keys

[MSG]

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?

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