Again, this can be right or wrong, depending on what's meant. Certainly, it avoids the password-length vulnerability just mentioned, if you're using a client that does not already address this by the padding technique. If you're doing consecutive SSH sessions, then using public-key authentication for the second connection can avoid the timing attack--if you use an SSH key agent on the first host, with agent forwarding to the second. Otherwise, you will end up typing in your passphrase on the second host to decrypt your SSH private key, and your passphrase will be exposed to timing analysis in the first SSH connection. Of course, your passphrase by itself is useless without also stealing your private key file, so the compromise is not immediate if your passphrase is cracked, but you still don't want that to happen.

Learn Dvorak.

It's not clear how much this would really help. Presumably, the same attack will work with model data derived from Dvorak typists instead. For all we know, it may be simple to guess whether someone is using QWERTY or Dvorak based on timing patterns as well. Even if not, running both models at once would yield a work reduction factor of 25 instead of 50 (assuming a Dvorak model is as equally effective as the QWERTY ones studied), which is still a serious problem. Besides, this is not terribly practical advice, since millions of people are simply not going to switch keyboard systems overnight (or at all).

While SRP is a cool protocol with much to recommend it, this idea misses the point just as does the previous exhortation to use public-key authentication: The problem is when you type in a password over an SSH terminal session, regardless of what spiffy thing is being done with the password once it's entered.

One-time passwords would be an improvement because they're typically much longer and useless by the time the attacker cracks them anyway (if the OTP system is well designed and administered).

Defenses

So, if timing analysis is such a problem, what do we do?

In the long term, if this sort of attack proves to be a serious problem, we will have to develop better protocols and deploy different networking technologies to address these attacks. Traffic analysis is a hard problem with no immediate, easy answers. The paper suggests some approaches, all of which need further research and testing:

Introduce random jitter into keystroke packets as they are sent. This obvious approach has problems, though, because if the jitter is in fact random, an observer may be able to filter it out over repeated timings of the same password.

Send a constant stream of packets even when idle, thus masking the real traffic among the fake. The dummy packet timings would have to be carefully crafted to be indistinguishable from the real ones, and the rate chosen is a tradeoff between security and both user-visible latency and network overhead.

In the short term, here are a few countermeasures that may help to varying degrees:

Defeat echoing signatures. Make it harder to guess the positions of passwords in a session by having the server simulate echoes using dummy messages when the client disables terminal echo. Of course, there are other ways to guess when passwords are being typed, but anything that makes it harder is good.

Don't use passwords on remote machines. To whatever extent possible, implement single sign-on: you should only have to enter passwords on your local machine. The ssh-agent available in many SSH implementations, together with agent forwarding and public-key authentication, provides this capability for SSH specifically. Combining SSH with a broader technology such as Kerberos, which also has a credential-forwarding feature, can give you the best of both worlds. The author uses a system whereby he can authenticate once, using Kerberos (kinit) on his local machine, then SSH elsewhere and he'll have access to not only other SSH servers, but also to Kerberized versions of su, secure Telnet authentication to Cisco routers, and so on. SSH1 has Kerberos-5 support, including ticket forwarding, and there is a patch for GSSAPI/Kerberos support in OpenSSH for protocol 2. Of course, it's almost impossible to get pervasive single sign-on in a heterogeneous system, but anything you do is an improvement.

Protect hashed passwords. As mentioned above, the attacker will want a verifier for performing an offline dictionary attack. Make her work for it! Make sure you're using shadow password files that are readable only by root, and do not store your password hashes in the world-readable /etc/passwd file. If you use NIS, use it with secure RPC to avoid revealing hashes over the network. If you use Kerberos or a similar third-party system, you can avoid having distributed password verifiers, instead keeping them on the single-purpose KDC's (key distribution centers), which are easier for you to secure than a bunch of general-purpose login hosts.

Conclusion

The issues raised in the paper by Song, Wagner, and Tian are not a reason for panic (as with, say, the announcement of a practical root exploit in deployed software). The attack presented is sophisticated and it has not yet demonstrated how well this research will translate into general real-world attacks. However, the issues are serious and real, and hopefully the paper will heighten awareness of traffic analysis as a threat and spur more research into practical countermeasures. In the meantime, users and system administrators should address what they can by considering the suggestions made in this article, which are, for the most part, already accepted security "best practices."

There is an optional TCP feature called the Nagle algorithm, which batches up sequential small TCP segments for better transmission efficiency. This would interfere with timing measurements; however, interactive applications often specifically turn off this feature by setting the TCP "NODELAY" option, in order to get better interactive response. OpenSSH, for example, does this.