ssh could buffer up the password until the user hits return, then send it all in on packet. I presume it doesn't do this because it doesn't want to keep track of a password mode? It will just let the remote machine handle the username/password prompting?
And inserting a random delay between keystrokes would be pretty annoying when typing your user name... Yeah, I guess that's not an easy problem to solve!
Posted Sep 18, 2008 4:38 UTC (Thu) by shapr (guest, #9077)
[Link]
Yeah, my first thought was, "send the password all at the same time."
My next thought is "try to use backspace in your password." Though that could also be found out if you always use backspace in the same position.
I suspect that use of dvorak or some other non-qwerty keyboard might make this a tetch more difficult.
Back to line-by-line input...
Posted Sep 18, 2008 5:30 UTC (Thu) by eru (subscriber, #2753)
[Link]
My next thought is "try to use backspace in your password."
Suppose ssh introduced a line-by-line mode, where editing like
backspace can be done locally by the ssh client? This would of
course require that all software you are trying to feed passwords
to will co-operate in setting the line-mode. Maybe this would
even need a new stty mode?
In the age of dinosaurs, these kinds of line-by-modes were normal
on non-Unix systems. In fact it was quite uncommon for apps to react to
individual characters from terminals. Editing was handled by "smart
terminals" or front-end machines, which fed complete lines (or even
complete filled forms) to The Real Computer.
OpenSSH and keystroke timings
Posted Sep 18, 2008 4:54 UTC (Thu) by jimbo (subscriber, #6689)
[Link]
I'm not a network expert, but aren't the SSH packets themselves encrypted?
It might be practicable to add noise into the plain text of a short packet, encrypt the whole thing (including the noise). The packet can then be decrypted, and the actual data extracted for use by the application.
--
Jimbo
OpenSSH and keystroke timings
Posted Sep 18, 2008 7:15 UTC (Thu) by bboissin (subscriber, #29506)
[Link]
The problem is the timing between packets, not the encryption.
not really
Posted Sep 18, 2008 7:20 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
how would ssh know that you are sending a password?
do you _really_ want your transport layer to start guessing at what strings may be password prompts that should shift you into line-based mode instead of character mode? what if that string shows up in the middle of an image while you are playing a game, do you really want it to start buffering all your keystrokes (and not showing you) until you hit enter?
the only fix for this is to waste bandwidth by sending garbage packets.
my solution, try to sidestep the problem by using hardware token based authentication wherever possible rather then passwords (even over encrypted links)
not really
Posted Sep 18, 2008 8:53 UTC (Thu) by epa (subscriber, #39769)
[Link]
how would ssh know that you are sending a password?
Password prompts already send special magic characters to the tty to turn off echoing. It would need only a small extension to su(1) or ssh(1) to make them echo a new sequence meaning 'I am reading a password now'. The remote ssh client would note this and batch up a whole line of input to send at once.
not really
Posted Sep 18, 2008 18:18 UTC (Thu) by djm (subscriber, #11651)
[Link]
Actually OpenSSH already defends against this case: we detect when echo is turned off and send fake echo (SSH2_MSG_IGNORE) packets back in responses to keystrokes. This makes it more difficult for an attacker to tell when the user is actually typing in a password.
OpenSSH and keystroke timings
Posted Sep 18, 2008 15:52 UTC (Thu) by docwhat (subscriber, #40373)
[Link]
Wouldn't do anything useful; ssh may already do this.
The problem is that if you ssh from a to b. Then ssh from b to c. If someone eavesdrops on your a-b connection, they will see the password for c being typed.