← Back to context

Comment by Ecco

2 days ago

How is password auth weaker than key auth? Bugs in auth code can happen in both pathways. And apart from stupidly short passwords both should be equally impossible to brute-force.

In other words, conceptually, at the end if the day, isn’t a key just another name for a password, really?

Password gets sent to the server. Private key does not get sent to the server, and authentication protocol can be forwarded safely, enabling things like ssh-agent, FIDO SSH keys. This is solvable with passwords (see: augmented PAKE), but `PasswordAuthentication` isn’t that. But there are also settings where none of this really matters, yes, to be fair if that’s what you’re referring to.

SSH certificates are cool too.

  • password doesn’t get sent to the server, hash does.

    but I guess that the hash is always the same unlike with pub priv key mechanism.

    • No. The password gets sent to the server. That said, I still enable passwords on servers, but don't ever share passwords between trust domains.

    • > password doesn’t get sent to the server, hash does.

      Kind of irrelevant what gets sent to the server and what happens on the server.

      Password is already easily defeatable long before it even leaves your computer, thanks to keyloggers and/or password manager breaches and/or old-school shoulder surfing (assisted in the 2026 era by covert filming and AI).

      All of which are not vulnerabilities with hardware-backed keys which you don't even need a Yubikey for these days since most modern computers and smartphones have secure enclaves and/or TPMs. (Yubikeys are still great though).

What people think of as a very strong password often has <100 "security bits" of entropy.

Keys are usually at least 128 bits of entropy, and it's easy to take them up to 256.

Yes, both are a shared secret, but password auth - even with challenge-response - is weaker than key auth exactly because key auth provides more guess resistance.

  • But the SSH keys are based on asymmetric crypto, not shared secrets.

    • That makes it impossible to steal the key if you MITM, but there is still the same chance of guessing it. (Assuming password has as many bits of pure randomness, such as machine generated password.)

  • > What people think of as a very strong password often has <100 "security bits" of entropy.

    The best password in the world will still be defeated by a simple keylogger or breach of your password manager.

    • The best cryptographic key in the world would be defeated by a breach of your filesystem.

      The comparison here is between in-memory cryptographic keys and in-memory passwords. Yeah typing a password into a keyboard adds a vulnerability in between the keyboard and the computer, but it's not a huge difference in security posture. If the device using the secret is compromised, so is the secret, whether it came from the user's mind or not, whether it was stored encrypted before the user used it or not.

      A physically separate hardware security module does add protection but I think that's a different conversation.

Password reuse is the problem. The password hash is stolen from some other site and brute forced offline.

  • Same issue with key reuse. Unless you have a policy to rotate them and verify which host they login from, someone's unencrypted hard drive from 5 years ago is more likely to have a key than password.

    • > someone's unencrypted hard drive from 5 years ago is more likely to have a key than password.

      Even 5+ years ago, hardware-backed SSH keys were a thing (Yubikey). The only difference today is that its 100% easier to do keys properly because of the widespread commoditisation of secure enclaves in desktops and smartphones to support FIDO, its basically free of charge now because you're not obliged to buy a Yubikey.

> How is password auth weaker than key auth?

Well, it's a heck of a lot weaker in this instance (at least when `PasswordAuthentication no`)

  • In this specific instance yes, but it seems like it could have about as easily been a perfect cascade of failures in janky libc routines for checking keys as opposed to janky libc routines checking passwords.