So this basically means to scan for this exploit remotely we'd need the private key of the attacker which we don't have. Only other option is to run detection scripts locally. Yikes.
Unless we find that this problem has somehow infested a lot of real world systems that seems to me even worse than the time similar "experts" decided that it was best to demand people rotate their passwords every year or so thereby ensuring the real security is reduced while on paper you claim you improved it.
If you use a different strong random password for every single server, this attack isn't a problem, but that adds a lot of management hassle compared to using a single private key. (It's also made more difficult by host key checking, but let's be honest, most of us don't diligently check the fingerprints every single time we get a mismatch warning.)
In contrast, if you use an SSH key, then a compromised server never actually gets a copy of your private key unless you explicitly copy it over. (If you're have SSH agent forwarding turned on, then during the compromised connection, the server can run a "confused deputy" attack to authenticate other connections using your agent's identity. But it loses that ability when you disconnect.)
Why would the password be sent in plaintext instead of, say, sending a hash of the password calculated with a salt that is unique per SSH server? Or something even more cryptographically sound.
In fact, passwords in /etc/shadow already do have random salts, so why aren't these sent over to the SSH client so it can send a proper hash instead of the plaintext password?
Even so, these protocols require the server to know your actual password, not just a hash of the password, even though the password itself never traverses the network. So a compromised server can still lead to a compromised credential, and unless you use different passwords for every server, we're back to the same problem.
If I am a server and have your public key in an authorized_keys file, I can just encrypt a random session key using that and only you will be able to decrypt it to finish setting up the session.
This is why passwords and asymmetric crypto are worlds apart in security guarantees.
The man in the middle can still perform denial of service, by dropping some or all of the traffic.
The man in the middle could substitute their own public key in place of one of the endpoint's public keys, but if each endpoint knows the other endpoint's key and is expecting that other key, then an unexpected substitute key will raise a red flag.
https://owasp.org/www-community/OWASP_Application_Security_F... says "Salted hash for transmitting passwords is a good technique. This ensures that the password can not be stolen even if the SSL key is broken."
I didn't want to believe you, but man, I just checked a few websites in the network inspector... and it seems like GMail, Hackernews, Wordpress, Wix, and Live.com all just sent it in plaintext with only SSL encryption :(
That's a bit disappointing. But TIL. Thanks for letting me know!
If TLS break then all is untrusted anyway! If you read hash as MITM you can replay it as pass equivalent and log in with hash, do not need knowledge of the original pass. You can just inject the script to exfilatrate original pass before hashing. CSP is broken, since you can edit header to give your own script a inline nonce. I think everything is reliant on TLS in end.
I think 10yr ago before TLS was 99%+ standard on all sites many people would come up with schemes, forums would md5 pass client side and send md5, all sorts were common. But now trust is in TLS.
I'm a little confused with this recommendation
How server is supposed to verify user's password in this case? Store the same hash with exactly the same salt in the database, effectively making the transmitted salted hash a cleartext password?
Edit: I guess the reverse is also true, that is, leaked user passwords from other sources can't be easily tested against your user accounts just by sending a bunch of HTTP requests to your server. The attacker would have to at least run the passwords through your particular salted hash scheme first (which they can get by reverse engineering your client, but it's extra labor and computation).
If you’re worried about passive listeners with ssl private keys, perfect forward secrecy at the crypto layer solved that a long time ago.
For browsers at least, sending passwords plainly over a tls session is as good as it gets.
If you salt and hash the password on the client side, how is the server going to verify the password. Everything I can think of either requires the server to store the plaintext password (bad) or basically makes the hashed bytes become the plaintext password (pointless).
There are password-based solutions that work like this --- PAKEs like Secure Remote Passwords: https://www.ietf.org/rfc/rfc2945.txt
They have low uptake because they don't really offer any security beyond just sending the plaintext password over a properly-functioning TLS channel.
But I think the point of salting + hashing the password isn't quite the same as what TLS offers. It's not necessarily to prevent MITM eavesdropping, but to help protect the user from credential re-use from leaks.
What was I taught is that your server should never have the user's cleartext password to begin with, only the salted hash. As soon as they set it, the server only ever gets (and saves) the salted hash. That way, in the worst case scenario (data leak or rogue employee), at most your users would only have their accounts with you compromised. The salted hashes are useless anywhere else (barring quantum decryption). To you they're password equivalents, but they turn the user's weak reused password (that they may be using for banking, taxes, etc.) into a strong salted hash that's useless anywhere else.
That's the benefit of doing it serverside, at least.
Doing it clientside, too, means that the password itself is also never sent over the wire, just the salted hash (which is all the server needs, anyway), limiting the collateral damage if it IS intercepted in transit. But with widespread HTTPS, that's probably not a huge concern. I do think it can help prevent accidental leaks, like if your auth endpoint was accidentally misconfigured and caching or logging requests with cleartext passwords... again, just to protect the user from leaks.
You can imagine the salted and hashed password in your scheme to be "the password". Because the server will still know it, and could use it to log in somewhere else (it just has to skip the salt-and-hash step).
Password auth involves sending your credentials to the server. They're encrypted, but not irreversibly; the server needs your plaintext username and password to validate them, and it can, in principle, record them to be reused elsewhere.
Public key and certificate-based authentication only pass your username and a signature to the server. Even if you don't trust the server you're logging into, it can't do anything to compromise other servers that key has access to.
Having some emergency access certs in a password manager might be a good backup (and rotating it after using it on an untrusted source?).
The best way is, however, removing the need in emergencies to access a machine (e.g. more of the "cattle vs pets" way of thinking). But that's hard for sure.
> ...the "cattle vs pets" way of thinking...
Good points both... To the former, of course you're right that once used, an emergency cert should be replaced, which could be onerous either from the point of view of having double the number of certs to manage (rather than one master key), or else having to rotate the master key on all servers. To the latter, I'm definitely thinking about pets, so I hadn't considered just throwing away the VM and starting again; that neatly sidesteps the issue.
Thanks!
* this enforces high entropy,
* the password is transmitted to the server, the private key is not.
Certificates can be revoked, they can have short expiry dates and due to centralized administration, renewing them is not terribly inconvenient.
On top of that they are a lot more difficult to read over the shoulder, to some degree that can be considered the second factor in a MFA scheme. Same reasons why passkeys are preferred over passwords lately. Not as secure as a HW-key, still miles better than “hunter2”.
Sadly that is not how normies use passwords. WE know what passwords managers are for. Vast majority of people outside our confined sphere do not.
In short: password rotation policies make passwords overall less secure, because in order to remember what the new password is, people apply patterns. Patterns are guessable. Patterns get applied to future password as well. This has been known to the infosec people since 1990's because they had to understand how people actually behave. It took a research paper[0], published in 2010, to finally provide sufficient data for that fact to become undeniable.
It still took another 6-7 years until the information percolated through to the relevant regulatory bodies and for them to update their previous guidance. These days both NIST and NCSC tell in very clear terms to not require password rotation.
0: https://www.researchgate.net/publication/221517955_The_true_...
The backdoor's signature verification should cost around 100us, so keys matching the fingerprint should take that much longer to process than keys that do not match it. Detecting this timing difference should at least be realistic over LAN, perhaps even over the internet, especially if the scanner runs from a location close to the target. Systems that ban the client's IP after repeated authentication failures will probably be harder to scan.
(https://bench.cr.yp.to/results-sign.html lists Ed448 verification at around 400k cycles, which at 4GHz amounts to 100us)
[1] https://www.openwall.com/lists/oss-security/2024/03/29/4
If you send a request to SSH to associate (agree on a key for private communications), signed by a specific private key, it will send the rest of the request to the "system" call in libc, which will execute it in bash.
So this is quite literally a "shellcode". Except, you know, it's on your system.
Of course since the backdoor was never widely deployed and is now public, I think it's unlikely the attacker will attempt to use it. So whether it's replayable doesn't have a practical impact now. I'm only asking about replayability because I'm curious how it's unreplayable.