4 ms·
This seems like an odd vulnerability. I use SSH keys instead, but I always imagined that if I used a password instead then my password would be used (on both th
by acchow 10y ago
This seems like an odd vulnerability. I use SSH keys instead, but I always imagined that if I used a password instead then my password would be used (on both the server and the client) to help derive private keys. If I have the wrong password, the encrypted messages we send to each other would just be garbled nonsense.
- hackcasual 10y agoSSH predates PAKE as a widely accepted practice
- vilhelm_s 10y agoIt seems like it should be really easy to fix too: add a proper authentication protocol, with protocol negotiation, and then in subsequent versions of SSH, make the warning messages more and more scary. Something like > The remote host 'ssh.overwathc.org' WANTS TO SEE YOUR PASSWORD, even though current versions of SSH can authenticate without revealing it. You have never connected to this host before -- it could be operated by an attacker. Are you sure you want to show your password to this host (yes/no)?
- tedunangst 10y agoReally easy...
- Johnny_Brahms 10y agoI think that would be "really easy" only if password hashing was done the same over all platforms SSH runs on. I wouldn't want to be the one to bolt on something like SRP on an already existing login system that uses subtly different "third party" mechanisms for authentification.
- GrinningFool 10y agoPrior to any authentication, a private session key is negotiated and used for encryption for the life of the session. The password (or proof of key ownership, or cert) used for auth is only used for auth, and is only sent after DH key negotiation is complete.
- minitech 10y agoThe server doesn’t have your password (just its hash), so it can’t derive a key from it.