64 ms·
There doesn't appear to be a way to prevent these attacks without locking out legitimate users There is, but I've never seen it implemented. Throttle login at
by dfranke 16y ago
There doesn't appear to be a way to prevent these attacks without locking out legitimate users
There is, but I've never seen it implemented. Throttle login attempts by requiring a cryptographic proof-of-work to accompany each attempt. Send the credentials and proof-of-work over UDP so that there's no connection state to hold open. Scale the required amount of work up and down based on the total number of incorrect attempts in the past minute. After a successful login, issue systems a long-lived cookie that exempts them from future proof-of-work requirements. That way, during attacks, legitimate users may experience a longer delay when trying to log in, but only if they've never logged in from that system before, and they can never be locked out completely.
- JoachimSchipper 16y agoProof-of-work systems are really neat, but that's cheating: if you make it optional, it doesn't work at all, and if you make it mandatory, you're arguably not speaking SSH anymore. Besides, I, too, do not recall any actually working implementations.
- dfranke 16y agoI meant this as a general answer to the brute-force-mitigation-without-DoS-vulnerability problem, not as something SSH-specific. Somewhere on my hard drive I have a half-finished draft of a spec for a Kerberos replacement implementing the idea.