I can answer the question of "how do they even manage to both read the password?"
A device file named /dev/tty exists. Linux (and more modern Unix) kernels arrange for /dev/tty to be different for every process that has a controlling TTY. That's all of the interactive processes, you'd have to go out of your way to write a program that doesn't have a controlling TTY. The "TTY" column of ps -l -p $$ will show you what your shell's TTY is. ps -el "TTY" column will show you the controlling TTY of all processes.
You can think of /dev/tty as a way to get what would ordinarily be stdin, but from the keyboard associated with the controlling TTY. You can try this out with the command cat < /dev/tty > spork in an Xterm window. Whatever you type, up to the terminating control-D, will end up in file "spork".
A lot of FTP and SSH clients use /dev/tty for password input, to avoid having a password show up in the environment or other crannies. Interactive clients can do open("/dev/tty", O_RDWR) no matter what the actual controlling TTY is, and get a file descriptor that in essence, is connected to the keyboard. Various system calls can be used to turn off echoing. You can test this by using a bash shell Xterm and running stty -echo. You'll have to type blind, but commands like ls, ps, etc clearly get to the shell and work. You can turn TTY echoing back on via stty echo.