Password authentication about sshx HOT 1 CLOSED

Hi, thanks for the short message. I think what's being proposed here is unclear because of the incorrect use of words like "leak" and "password" vs "public key" (these are different things!) — I'll try to address all interpretations.

1. Generate a one-time password along with the link to a new session and require users to present it upon joining.

   This is already effectively done through the private encryption key attached to the URL in the hash field #. This affix is never sent to any server while making an HTTP request, and adding a second password to the mix would not improve security beyond allowing users to send parts of the link over two different communication media.

2. Allow users to authenticate via a public/private key pair to verify their identity before connecting to a server.

   This is a reasonable approach to some systems, and ssh does this to allow for persistent access. But it takes a lot of time to set up, and creates friction — people don't just have keypairs lying around to copy/paste. If you'd like to share access to your computer this way, you should add the public key to your authorized_keys file and use ordinary SSH. For a real-time computer access system, you would need to communicate the public key over some other channel regardless, and if that channel were breached an attacker could edit the sent public key file anyway.

In either case, sshx is completely secure as-is assuming confidential communication of the link, and if you do not assume this, then both sshx and all of the alternatives are equally insecure. The suggested alternatives simply add friction to both attackers and regular users. But while this affects ordinary users greatly, attackers have unlimited resources — security through obscurity is not security.

If you have a compelling argument for why either approach would improve security, I'm happy to hear it. You would need to define a security model and provide examples of attacks that would be prevented.

from sshx.